DEV Community

Cover image for Economic State Estimation Under Partial Observability: Reconstructing Financial Truth from Incomplete Evidence
Mayckon Giovani
Mayckon Giovani

Posted on

Economic State Estimation Under Partial Observability: Reconstructing Financial Truth from Incomplete Evidence

#distributedsystems #fintech #sre #systemdesign

Abstract

A distributed financial system almost never observes its complete economic state directly.

The internal ledger knows which entries it committed. A payment processor knows which instructions it accepted. A bank knows which transactions it booked. A blockchain node knows which state it currently considers canonical. A custody system knows which signatures it produced. Reconciliation knows which records it managed to match. None of these systems, individually, knows the full economic truth.

They provide observations.

Those observations arrive at different times, carry different authority, describe different domains, and can contradict one another. Some are definitive. Some are provisional. Some are stale. Some confirm that an event happened. Others merely fail to show that it happened.

The platform must still make decisions.

Can these funds be withdrawn? Has settlement completed? Is this liquidity real? Can another transaction be admitted? Should a provider be quarantined? Does a negative balance represent customer debt, ingestion lag, or an unresolved external movement?

These are state-estimation problems.

This article examines financial infrastructure under partial observability. We develop a model in which external events are treated as evidence about latent economic state rather than direct state mutations. We explore observation time, effective time, evidence authority, contradictory observations, uncertainty bounds, stale evidence, negative evidence, admission control, reconciliation, deterministic reconstruction, and the difference between estimating what probably happened and proving what the system may safely assume.

The central problem is simple:

The system must act before it knows everything.

The architecture determines what it is allowed to believe.

Financial truth is distributed

Consider a withdrawal.

Internally, the sequence may appear straightforward:

Customer requests withdrawal
Funds are reserved
Compliance approves
Custody signs
Transaction is submitted
Provider reports success
Ledger marks completed
Enter fullscreen mode Exit fullscreen mode

The transaction appears finished.

Now ask the bank.

It may say:

No settlement record yet.
Enter fullscreen mode Exit fullscreen mode

Ask the processor:

Accepted for processing.
Enter fullscreen mode Exit fullscreen mode

Ask reconciliation:

No corresponding entry observed in today's file.
Enter fullscreen mode Exit fullscreen mode

Ask treasury:

Liquidity decreased by approximately the expected amount.
Enter fullscreen mode Exit fullscreen mode

Ask the receiving institution:

Funds not yet available.
Enter fullscreen mode Exit fullscreen mode

All of these observations can be simultaneously true.

The contradiction exists only if the platform tries to collapse them into one state:

status = completed
Enter fullscreen mode Exit fullscreen mode

The underlying economic event has several dimensions, and no observer necessarily sees all of them.

This is partial observability.

The state exists whether you can see it or not

Let the real economic state at time t be:

x(t)
Enter fullscreen mode Exit fullscreen mode

This state may include:

actual settlement position
actual external balances
pending obligations
reversal exposure
available liquidity
provider commitments
customer claims
collateral state
Enter fullscreen mode Exit fullscreen mode

The platform does not observe x(t) directly.

Instead, each source produces some observation:

y_i(t) = H_i(x(t), delay_i, faults_i)
Enter fullscreen mode Exit fullscreen mode

where H_i describes what source i can reveal.

A bank API may reveal booked transactions.

A processor webhook may reveal processing status.

A blockchain node may reveal its current canonical chain.

A reconciliation file may reveal yesterday's settled movements.

An internal ledger reveals exactly what the platform itself recorded.

Each observation is a projection of the state.

None is automatically the state itself.

Events are claims

Distributed systems often treat incoming events as commands to mutate state.

A provider sends:

PaymentCompleted
Enter fullscreen mode Exit fullscreen mode

and the application writes:

status = completed
Enter fullscreen mode Exit fullscreen mode

That is convenient.

It is also stronger than the evidence actually supports.

The provider did not send global truth.

It sent a claim:

Provider P claims operation O reached state S at time T.
Enter fullscreen mode Exit fullscreen mode

A better representation preserves that distinction.

Observation:
    subject: operation_8841
    source: provider_A
    claim: settlement_completed
    source_time: 14:02:10
    observed_at: 14:02:14
    evidence_reference: event_7718
Enter fullscreen mode Exit fullscreen mode

The platform can then evaluate the claim against other evidence.

This matters enormously once sources disagree.

Authority is contextual

Not all evidence sources have the same authority.

But authority is not globally ordered.

A payment processor may be authoritative about whether it accepted an instruction.

It may not be authoritative about whether the receiving bank finally booked the funds.

The internal ledger is authoritative about internal accounting entries.

It is not authoritative about external settlement.

A blockchain node is authoritative only relative to the network state it currently observes. Depending on the network, an observed inclusion may still be subject to reorganization.

Therefore:

authority(source)
Enter fullscreen mode Exit fullscreen mode

is too simplistic.

The useful question is:

authority(source, claim_type, domain)
Enter fullscreen mode Exit fullscreen mode

For example:

Custody service:
    authoritative for signature creation
    not authoritative for chain inclusion

Blockchain node:
    authoritative for observed chain state
    not authoritative for legal ownership

Bank statement:
    authoritative for booked bank entry
    not necessarily authoritative for application intent
Enter fullscreen mode Exit fullscreen mode

This prevents one successful observation from being promoted into claims it cannot support.

Observation time is not event time

Financial systems often contain several clocks for one event.

Suppose a bank books a transfer at 14:00.

The API reports it at 14:07.

The platform polls at 14:10.

Reconciliation imports the record at 02:00 the next day.

Which timestamp represents the transaction?

All of them describe something different.

A robust evidence record may need:

effective_at
source_recorded_at
observed_at
ingested_at
processed_at
Enter fullscreen mode Exit fullscreen mode

These answer different questions.

effective_at describes when the economic event takes effect according to the source domain.

source_recorded_at describes when the source recorded it.

observed_at describes when the platform first saw evidence.

ingested_at describes when that evidence entered internal infrastructure.

processed_at describes when the state estimator incorporated it.

These clocks can diverge substantially.

That divergence is not metadata noise.

It is where hidden exposure often lives.

The observation gap

Suppose:

Bank booked settlement: 14:00
Platform observes settlement: 14:20
Enter fullscreen mode Exit fullscreen mode

For twenty minutes, reality and the platform's model disagree.

The transfer was settled externally.

Internally, it remained unresolved.

This may cause unnecessary restrictions, but it is conservative.

Now reverse the situation:

Processor reports success: 14:00
Bank settlement actually occurs: 14:20
Enter fullscreen mode Exit fullscreen mode

If the platform interprets processor success as bank settlement, it believes funds exist twenty minutes before they actually do.

That can create spendable value backed only by an assumption.

The second error is usually more dangerous.

This leads to an important asymmetry.

State estimation for financial safety should not necessarily optimize for the most likely state.

It often needs to optimize for the safest justified state.

Expected state versus admissible state

Suppose the system estimates:

95% probability settled
5% unresolved
Enter fullscreen mode Exit fullscreen mode

A statistical estimator might choose:

settled
Enter fullscreen mode Exit fullscreen mode

because it is the most likely outcome.

A financial admission controller may need to choose:

not yet spendable
Enter fullscreen mode Exit fullscreen mode

because the 5% unresolved branch creates unacceptable downside.

This is the difference between:

What state do we think exists?
Enter fullscreen mode Exit fullscreen mode

and:

What state are we justified in acting upon?
Enter fullscreen mode Exit fullscreen mode

Those are different questions.

A useful architecture keeps both.

EstimatedState:
    likely_state
    evidence

AdmissibleState:
    safe_permissions
    required_proof
Enter fullscreen mode Exit fullscreen mode

The estimator may believe settlement probably occurred.

The controller may still refuse irreversible withdrawals until stronger evidence arrives.

Bounds are often more useful than point estimates

Financial systems frequently force uncertainty into one number.

For example:

available_liquidity = 12M
Enter fullscreen mode Exit fullscreen mode

But perhaps:

10M is confirmed
2M is strongly expected
3M is unresolved
Enter fullscreen mode Exit fullscreen mode

A safer representation might be:

confirmed_liquidity_lower_bound = 10M
probable_liquidity = 12M
possible_liquidity_upper_bound = 15M
Enter fullscreen mode Exit fullscreen mode

Different decisions can use different bounds.

Treasury forecasting may use the probable estimate.

A hard withdrawal invariant may use the confirmed lower bound.

Scenario analysis may use the upper and lower bounds.

This is much more honest than pretending all 15M has identical evidentiary quality.

Safety decisions should consume lower bounds

Suppose:

confirmed liquidity: 10M
probable additional settlement: 4M
requested irreversible withdrawals: 12M
Enter fullscreen mode Exit fullscreen mode

The expected-state view says:

14M expected > 12M requested
Enter fullscreen mode Exit fullscreen mode

Looks safe.

The hard-evidence view says:

10M confirmed < 12M requested
Enter fullscreen mode Exit fullscreen mode

The missing 2M would be platform credit.

That may be acceptable.

But it must be represented as credit.

It should not emerge accidentally from optimistic estimation.

The correct decomposition becomes:

withdrawal funding:
    10M confirmed liquidity
    2M approved platform credit
Enter fullscreen mode Exit fullscreen mode

Now the risk has an owner.

Evidence has freshness

An observation loses value as time passes.

Suppose a bank balance was confirmed at 10:00.

At 10:01, it is strong evidence.

At 18:00, after thousands of transactions, it may tell you almost nothing about current liquidity.

Evidence therefore needs an age.

Conceptually:

freshness = now - observed_at
Enter fullscreen mode Exit fullscreen mode

But not every source decays at the same rate.

A signed immutable settlement record may remain strong indefinitely.

A balance snapshot may become stale within seconds.

A provider-health heartbeat may become useless after a minute.

So evidence quality depends on both:

source semantics
age
Enter fullscreen mode Exit fullscreen mode

Not simply time.

Silence is not negative evidence

This distinction causes endless production bugs.

Suppose the platform asks a bank API for transaction T.

The API does not return it.

Can the platform conclude:

T did not settle
Enter fullscreen mode Exit fullscreen mode

Not necessarily.

The transaction may be outside the query window.

The API may lag.

Pagination may not have reached it.

A cursor may be stale.

The bank may expose pending and booked transactions through different endpoints.

The query itself may have failed partially.

Absence of observation is not automatically observation of absence.

A negative observation is meaningful only when the source semantics support that conclusion.

For example:

Authoritative settlement file covering window W
contains complete results for all transactions in W
transaction T absent
Enter fullscreen mode Exit fullscreen mode

This may be meaningful negative evidence.

Compare that with:

GET /transactions returned first 100 records
T not present
Enter fullscreen mode Exit fullscreen mode

Those are not equivalent.

Coverage belongs to evidence

An observation should record not only what it contains, but what it claims to cover.

For example:

Evidence:
    source: Bank A
    type: settlement_file
    period: 2026-09-20T00:00..23:59
    completeness: authoritative
    cursor: final
Enter fullscreen mode Exit fullscreen mode

Now absence can have meaning.

Without coverage semantics, the system cannot distinguish:

not present
Enter fullscreen mode Exit fullscreen mode

from:

not looked at
Enter fullscreen mode Exit fullscreen mode

Humans somehow continue rediscovering this distinction every time pagination is introduced.

Contradictory evidence is a state

Suppose the system has:

processor: completed
bank API: pending
balance movement: observed
settlement file: missing
Enter fullscreen mode Exit fullscreen mode

A common implementation chooses one source according to priority.

That may be correct if authority ordering is clear.

But sometimes the contradiction itself is economically meaningful.

The state should then become:

conflicting_evidence
Enter fullscreen mode Exit fullscreen mode

rather than:

completed
Enter fullscreen mode Exit fullscreen mode

or:

failed
Enter fullscreen mode Exit fullscreen mode

This conflict can reduce permissions.

For example:

ledger balance visible: yes
internal transfer: allowed
external withdrawal: blocked
manual investigation: required
Enter fullscreen mode Exit fullscreen mode

The system does not need to stop existing because two providers disagree.

It does need to stop pretending they agree.

Evidence lattices

One useful mental model is to treat settlement knowledge as a partially ordered set rather than a flat enum.

Consider:

NoEvidence
    |
    v
ObservedIntent
    |
    v
ProviderAccepted
    |
    v
ExternalInclusion
    |
    v
ConfirmedSettlement
    |
    v
Reconciled
Enter fullscreen mode Exit fullscreen mode

Knowledge becomes stronger as evidence accumulates.

But reversals complicate this.

A later return does not move backward from ConfirmedSettlement to NoEvidence.

It adds a new fact:

ConfirmedSettlement
    +
LaterReversal
Enter fullscreen mode Exit fullscreen mode

This is why state estimation should preserve history.

Knowledge is monotonic even when economic effect is not.

The system learned that settlement happened.

It later learned that a reversal also happened.

Both remain true.

Facts should not be overwritten by interpretations

Suppose a transaction was once considered settled and later reversed.

A naive row becomes:

status = reversed
Enter fullscreen mode Exit fullscreen mode

The system has lost the earlier fact that it was settled before reversal.

A better model preserves observations:

Observation 1:
    settled

Observation 2:
    reversed
Enter fullscreen mode Exit fullscreen mode

The derived economic state becomes:

settled_then_reversed
Enter fullscreen mode Exit fullscreen mode

Interpretations can change.

Evidence should remain immutable.

The estimator is a projection

A state estimator consumes evidence and produces a derived state.

Conceptually:

EstimatedState =
    Evaluate(
        EvidenceSet,
        EstimationPolicy
    )
Enter fullscreen mode Exit fullscreen mode

This is similar to reconciliation, but performed continuously.

The evidence set may include:

ledger events
provider events
bank observations
blockchain observations
settlement files
custody records
balance snapshots
manual decisions
Enter fullscreen mode Exit fullscreen mode

The estimation policy determines what conclusions are justified.

Estimation policy must be versioned

Suppose policy version 7 considered processor confirmation sufficient for operational settlement.

Policy version 8 requires bank evidence as well.

Historical replay under version 8 would reinterpret old transactions.

That may be useful analytically.

It is not historical truth.

The system should preserve:

estimation_policy_digest
Enter fullscreen mode Exit fullscreen mode

with each material decision.

For example:

SettlementEstimate:
    operation_id
    evidence_ids
    policy_digest
    derived_state
    evaluated_at
Enter fullscreen mode Exit fullscreen mode

Then the platform can answer:

What did we believe at the time?
Why?
Using which policy?
Enter fullscreen mode Exit fullscreen mode

Reproducibility requires evidence snapshots

Policy version alone is insufficient.

Suppose proportional exposure depends on:

pool state
provider headroom
current liquidity
Enter fullscreen mode Exit fullscreen mode

Replaying the same policy later against different input state produces another answer.

Therefore material state-estimation decisions should preserve the inputs used.

That does not necessarily mean copying entire databases.

It may mean preserving:

state version
evidence IDs
snapshot digest
cursor positions
Enter fullscreen mode Exit fullscreen mode

The important property is that the decision can be reconstructed from the historical evidence actually available at that moment.

Arrival order matters

Distributed evidence does not arrive in economic order.

Consider:

14:00 bank books transfer
14:01 processor sends confirmation
14:05 application receives processor confirmation
14:08 reconciliation file reports settlement
14:10 delayed bank webhook arrives carrying 14:00 timestamp
Enter fullscreen mode Exit fullscreen mode

If the estimator processes events strictly by arrival order, historical state may appear inconsistent.

This is a classic stream-processing problem with financial consequences.

The architecture should distinguish:

event time
observation time
processing time
Enter fullscreen mode Exit fullscreen mode

Late evidence may refine earlier estimates.

But it should not silently rewrite decisions that were already made based on weaker evidence.

Historical state and current interpretation

Suppose the platform released funds at 14:05.

At 14:10 it receives evidence showing that the bank actually settled at 14:00.

Current knowledge says:

settlement had already happened
Enter fullscreen mode Exit fullscreen mode

Historical decision provenance still says:

at 14:05 we did not yet possess that evidence
Enter fullscreen mode Exit fullscreen mode

This distinction is crucial.

Otherwise postmortems become contaminated by hindsight.

The system may look safer historically than it really was because later evidence is projected backward.

Hindsight-safe auditing

For every material decision, the audit system should answer:

Evidence available then
Decision made then
Policy active then
Evidence learned later
Current interpretation
Enter fullscreen mode Exit fullscreen mode

That is much stronger than reconstructing history from the database's current rows.

Current state knows too much.

Reconciliation is state estimation with stronger evidence

Periodic reconciliation is often treated as a separate subsystem.

Conceptually, it is another stage of estimation.

The difference is that reconciliation usually has access to stronger or broader evidence.

During real-time processing, the platform may know:

processor accepted
bank result unknown
Enter fullscreen mode Exit fullscreen mode

Later reconciliation may know:

processor accepted
bank booked
external amount matched
fee matched
balance movement matched
Enter fullscreen mode Exit fullscreen mode

The estimator can therefore strengthen the state:

operationally_settled
    ->
reconciled
Enter fullscreen mode Exit fullscreen mode

Reconciliation does not merely fix mistakes.

It upgrades the quality of knowledge.

Unreconciled is an economic state

If reconciliation is part of evidence acquisition, then an unreconciled transaction is not merely an accounting backlog.

It represents unresolved epistemic state.

Suppose:

500M nominally settled
100M still unreconciled
Enter fullscreen mode Exit fullscreen mode

The relevant risk question is not simply:

When will the batch finish?
Enter fullscreen mode Exit fullscreen mode

It is:

How much economic commitment depends on conclusions that have not yet received reconciliation-grade evidence?
Enter fullscreen mode Exit fullscreen mode

That may influence liquidity, reserves, and admission limits.

State estimation should constrain admission

This is where the previous control problem becomes concrete.

Suppose Provider A has:

hard exposure limit: 10M
confirmed unresolved: 4M
known in-flight commitments: 2M
probable but not yet observed commitments: 1M
Enter fullscreen mode Exit fullscreen mode

The platform should not allow another 6M simply because the current provider feed shows only 4M unresolved.

The estimator feeds admission control:

safe_remaining_capacity =
    hard_limit
    - confirmed_unresolved
    - known_inflight
    - safety_margin
Enter fullscreen mode Exit fullscreen mode

The monitor may update slowly.

Admission happens synchronously.

This distinction prevents delayed observation from creating unbounded overshoot.

Known in-flight state is not uncertain

An interesting asymmetry exists here.

The platform may not know whether external settlement occurred.

But it knows which commitments it already accepted.

Those commitments should be counted immediately.

For example:

Provider feed:
    sees 3M pending

Internal admission system:
    knows another 2M has already been accepted but not yet submitted

Risk exposure:
    at least 5M
Enter fullscreen mode Exit fullscreen mode

Using only external observations would underestimate the state.

The estimator should combine internal certainty with external uncertainty.

Lower-bound and upper-bound exposure

For some variables, a range is more honest than a point.

Suppose:

confirmed unresolved: 5M
known in-flight: 2M
possibly accepted externally but not yet observable: up to 1M
Enter fullscreen mode Exit fullscreen mode

Then:

unresolved_exposure_lower_bound = 7M
unresolved_exposure_upper_bound = 8M
Enter fullscreen mode Exit fullscreen mode

Admission control may use:

8M
Enter fullscreen mode Exit fullscreen mode

because that is the conservative bound.

Forecasting may use an expectation somewhere between them.

Again, the same system can maintain several interpretations for different purposes.

Unknown does not mean infinite risk

Conservative design does not mean treating every missing observation as catastrophic.

Uncertainty should be bounded where possible.

Suppose a provider API is silent.

The platform still knows:

maximum amount submitted since last confirmed observation
Enter fullscreen mode Exit fullscreen mode

That gives an upper bound on unknown exposure.

For example:

last confirmed state: 4M unresolved
new submissions since then: 800k
Enter fullscreen mode Exit fullscreen mode

Even with zero provider response:

unresolved exposure <= 4.8M
Enter fullscreen mode Exit fullscreen mode

This is much better than either:

assume still 4M
Enter fullscreen mode Exit fullscreen mode

or:

unknown, stop universe
Enter fullscreen mode Exit fullscreen mode

Bounded uncertainty gives the controller room to operate safely.

Observability itself should be measured

A financial system should know which parts of its economic state it can actually observe well.

For each domain, define something like:

ObservationCoverage:
    source
    claim_type
    expected_frequency
    last_success
    maximum_expected_delay
    completeness
    independent_confirmation_available
Enter fullscreen mode Exit fullscreen mode

Then the platform can reason about observability quality directly.

A provider with minute-level confirmation and independent daily reconciliation is not equivalent to one that sends one opaque CSV per week.

Yet both may appear as:

provider_status = healthy
Enter fullscreen mode Exit fullscreen mode

in ordinary service monitoring.

Technical health is not economic observability

A provider API can have:

HTTP success rate: 100%
latency: 50ms
Enter fullscreen mode Exit fullscreen mode

while returning data twenty minutes behind reality.

From an infrastructure perspective, it is healthy.

From a state-estimation perspective, it is degraded.

This suggests metrics such as:

evidence_age
source_lag
unresolved_exposure
conflicting_evidence_count
unconfirmed_commitments
reconciliation_lag
coverage_gap
Enter fullscreen mode Exit fullscreen mode

These are observability metrics in the literal sense.

They measure how well the platform can see its economic state.

Observability debt

Systems accumulate observability debt when economic decisions depend on states they cannot independently verify.

Examples include:

provider reports settlement but no independent statement exists
custody reports balances without transaction-level export
bank exposes booked entries only through delayed files
processor has no stable idempotency reference
reconciliation lacks source cursor provenance
Enter fullscreen mode Exit fullscreen mode

Every such gap creates a region of state that the platform must estimate through weaker evidence.

That is manageable if explicitly bounded.

It becomes dangerous when the architecture treats the weak evidence as equivalent to direct observation.

Independent evidence reduces common-mode error

Suppose two APIs report that settlement succeeded.

If both APIs read the same backend, they are not independent evidence.

They are two interfaces to one claim.

Evidence diversity matters.

For example:

processor webhook
bank transaction feed
bank balance movement
settlement file
Enter fullscreen mode Exit fullscreen mode

may provide progressively more independent confirmation.

But even these can share hidden infrastructure.

Therefore evidence architecture has the same correlation problem as risk architecture.

Two agreeing sources are valuable only to the extent that their failure modes differ.

Evidence dependency graph

The platform may need to know where observations originate.

For example:

Provider Webhook ----\
                      -> Provider Database
Provider REST API ---/

Bank Statement --------> Banking Core

Balance API ------------> Banking Core
Enter fullscreen mode Exit fullscreen mode

Two provider observations are correlated.

Two banking observations may also be correlated.

This does not make them useless.

It changes how much confidence agreement should add.

Probabilistic estimation has limits

It is tempting to assign probabilities to everything.

For example:

P(settled) = 0.997
Enter fullscreen mode Exit fullscreen mode

This can be useful for forecasting or optimization.

But probabilities become dangerous when they conceal structural uncertainty.

If the model does not know that two evidence sources depend on the same upstream system, its confidence can become absurdly high.

The mathematical precision does not repair the missing dependency.

A probability is only as meaningful as the model that produced it.

For hard financial safety, structural bounds and explicit proof requirements are often more reliable than confidence alone.

Proof classes

Instead of only assigning confidence, the system may classify conclusions by evidence strength.

For example:

Observed:
    source reported the event

Corroborated:
    multiple relevant observations agree

Authoritative:
    domain authority confirms the event

Reconciled:
    independent accounting evidence agrees

Final:
    applicable reversal and settlement policy considers the event sufficiently complete
Enter fullscreen mode Exit fullscreen mode

These are semantic claims, not percentages.

The controller can then require different proof classes for different actions.

For example:

internal display:
    Observed

internal transfer:
    Corroborated

external withdrawal:
    Authoritative

treasury release:
    Reconciled
Enter fullscreen mode Exit fullscreen mode

The exact rules depend on the product.

The architecture makes them explicit.

Different actions require different evidence

This is perhaps the most important practical consequence.

There is no single question:

Is the transaction settled?
Enter fullscreen mode Exit fullscreen mode

There are several:

Can we display it?
Can the customer trade against it?
Can it move internally?
Can it leave the platform?
Can treasury count it as deployable liquidity?
Can finance treat it as reconciled?
Enter fullscreen mode Exit fullscreen mode

Each action has a different loss profile.

Therefore each can require a different evidentiary threshold.

State estimation becomes permission-oriented.

A permission model

Instead of deriving one status, the estimator may derive capabilities:

EconomicPermissions:
    displayable
    internally_transferable
    tradable
    withdrawable
    treasury_usable
    accounting_reconciled
Enter fullscreen mode Exit fullscreen mode

For example:

processor accepted
bank unresolved

displayable = true
internally_transferable = true
tradable = false
withdrawable = false
treasury_usable = false
accounting_reconciled = false
Enter fullscreen mode Exit fullscreen mode

As stronger evidence arrives, permissions increase.

This is much harder to misuse than a universal completed flag.

Monotonic permission acquisition

Where possible, evidence should grant stronger permissions monotonically.

For example:

Observed
    -> Corroborated
        -> Authoritative
            -> Reconciled
Enter fullscreen mode Exit fullscreen mode

But reversals can remove economic permissions.

The important distinction is:

Knowledge remains monotonic.

Permissions need not.

After a reversal:

knowledge:
    settlement occurred
    reversal occurred

permissions:
    withdrawal based on original settlement revoked
Enter fullscreen mode Exit fullscreen mode

This keeps history intact while allowing current risk policy to change.

Failure modes in the estimator

The estimator itself becomes critical infrastructure.

It can fail through:

duplicate evidence
missing evidence
out-of-order evidence
stale cursors
incorrect source authority
clock skew
policy bugs
partial replay
corrupted snapshots
Enter fullscreen mode Exit fullscreen mode

Therefore estimator correctness must be testable.

At minimum, it should preserve several invariants.

Evidence preservation

Every derived state should be explainable by evidence.

DerivedState
    -> EvidenceSet
Enter fullscreen mode Exit fullscreen mode

No unexplained transition should exist.

No evidence fabrication

The estimator should never infer stronger evidence merely because time passed.

unresolved + time != settled
Enter fullscreen mode Exit fullscreen mode

unless the domain policy explicitly defines a time-based legal or operational transition.

Admission conservatism

Hard financial permissions should be based on evidence appropriate to their downside.

irreversible_outflow
    -> sufficient_settlement_evidence
       OR explicit_credit_decision
Enter fullscreen mode Exit fullscreen mode

If proof is insufficient, the system may still proceed.

But the difference must become an explicit risk transfer.

Evidence conflict preservation

Contradictory evidence should remain visible.

The estimator may select an operational interpretation, but it should not delete the conflict that required that interpretation.

Rebuildability

Given:

evidence log
policy digest
decision-time inputs
Enter fullscreen mode Exit fullscreen mode

the estimator should reconstruct the same historical result.

This is particularly important when estimation controls money movement.

Rust model

A minimal type model might separate evidence from conclusions:

#[derive(Debug, Clone, PartialEq, Eq)]
pub enum SettlementClaim {
    Submitted,
    Accepted,
    Included,
    Settled,
    Reversed,
}

#[derive(Debug, Clone)]
pub struct Evidence {
    pub evidence_id: String,
    pub operation_id: String,
    pub source: String,
    pub claim: SettlementClaim,
    pub source_time: u64,
    pub observed_at: u64,
    pub authority_class: AuthorityClass,
}

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum AuthorityClass {
    Informational,
    Operational,
    Authoritative,
    ReconciliationGrade,
}

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum EconomicState {
    NoEvidence,
    Observed,
    OperationallyAccepted,
    ExternallyConfirmed,
    Reconciled,
    Reversed,
    ConflictingEvidence,
}
Enter fullscreen mode Exit fullscreen mode

The important part is not the enum.

It is that Evidence survives independently from EconomicState.

The state can be recomputed.

The evidence should not be rewritten to fit the conclusion.

Decision provenance

Suppose the estimator marks a transaction externally confirmed.

The decision record should contain:

StateEstimationDecision:
    operation_id
    previous_state
    derived_state
    evidence_ids
    policy_digest
    state_snapshot_reference
    evaluated_at
Enter fullscreen mode Exit fullscreen mode

If that decision unlocks 5M of withdrawals, the platform now knows exactly what evidence authorized that economic consequence.

This connects state estimation directly to decision provenance.

Estimation and control must remain separate

The estimator answers:

What can we currently justify believing?
Enter fullscreen mode Exit fullscreen mode

The controller answers:

Given that belief, what may we safely do?
Enter fullscreen mode Exit fullscreen mode

They should not be the same subsystem.

Suppose the estimator concludes:

settlement probably complete
Enter fullscreen mode Exit fullscreen mode

The control policy may still decide:

no external withdrawal until reconciliation
Enter fullscreen mode Exit fullscreen mode

Separating the two prevents evidence semantics from being contaminated by product risk appetite.

The estimator describes knowledge.

The controller assigns permissions.

Why this matters during incidents

During normal operation, optimistic and conservative estimates often converge quickly.

Incidents expose the difference.

A provider becomes silent.

Settlement files arrive late.

Bank APIs disagree.

Reconciliation falls behind.

Blockchain observations diverge.

Now the system has to operate for hours inside uncertainty.

If its state model supports only:

success
failed
pending
Enter fullscreen mode Exit fullscreen mode

operators begin manually inventing intermediate semantics.

Someone updates a database.

Someone disables a worker.

Someone creates a spreadsheet.

Someone tells treasury not to trust a balance field.

At that point the real state machine exists in human conversation rather than software.

That is where incidents become expensive.

State-estimation degradation modes

A mature platform should degrade according to observability quality.

For example:

FULL_OBSERVABILITY:
    normal availability

DEGRADED_OBSERVABILITY:
    reduced provisional limits

INSUFFICIENT_EVIDENCE:
    settled-only availability

CONFLICTING_EVIDENCE:
    affected domain quarantined

RECONCILIATION_ONLY:
    no new irreversible commitments
Enter fullscreen mode Exit fullscreen mode

The important point is that observability failure can change economic permissions even when transaction processing services remain technically online.

Recovery requires evidence, not optimism

Suppose a bank feed was silent for two hours.

It begins responding again.

That is evidence that connectivity recovered.

It is not proof that the two missing hours reconciled.

Recovery should require:

fresh connectivity
missing windows backfilled
unresolved exposure reconciled
conflicts resolved
liquidity state refreshed
Enter fullscreen mode Exit fullscreen mode

Only then should the system restore full permissions.

Otherwise the platform reconnects to the observer while remaining blind to the incident interval.

The estimator can become a systemic dependency

Once availability, treasury, reconciliation, and risk depend on the state estimator, its failure can affect the entire platform.

That requires isolation.

A corrupted estimator should not silently grant stronger permissions.

Safe failure should generally bias toward:

retain known accounting state
reduce new economic permissions
preserve unresolved evidence
Enter fullscreen mode Exit fullscreen mode

not:

assume everything settled
Enter fullscreen mode Exit fullscreen mode

This is one of those areas where fail-open is an admirably efficient way to transform a monitoring bug into a balance-sheet event.

Observability budgets

Just as systems maintain latency and error budgets, financial infrastructure can maintain observability budgets.

For example:

maximum unreconciled value
maximum evidence age
maximum conflicting exposure
maximum unconfirmed external commitments
maximum reconciliation lag
Enter fullscreen mode Exit fullscreen mode

When these budgets are consumed, permissions degrade.

This turns observability from a passive dashboard concern into an explicit economic resource.

Epistemic capacity

The broader idea is that the system has a finite capacity to operate under uncertainty.

Call this epistemic capacity.

When evidence is fresh and consistent, that capacity is largely unused.

When providers become silent, reconciliation falls behind, or observations conflict, uncertainty consumes it.

Conceptually:

epistemic_headroom =
    uncertainty_limit
    - unresolved_state
    - conflicting_state
    - stale_state
Enter fullscreen mode Exit fullscreen mode

New commitments consume headroom.

Fresh evidence restores it.

This is not a literal universal formula.

It is a useful architectural principle.

The platform should have a bounded amount of economic activity it is willing to conduct without sufficient knowledge.

Financial systems are epistemic machines

At first glance, financial infrastructure appears to move money.

At a deeper level, much of the architecture exists to establish knowledge about money.

Did the customer authorize this?

Did the bank accept it?

Did settlement occur?

Did the blockchain include it?

Is the asset still reversible?

Does the platform have enough liquidity?

Did the external record match the internal one?

Every one of these questions is about evidence.

The economic action follows from what the system believes the evidence justifies.

That means correctness depends not only on state transitions.

It depends on the rules by which observations become beliefs and beliefs become permissions.

Conclusion

Distributed financial systems operate under partial observability by default.

The ledger sees internal accounting.

Processors see instructions.

Banks see booked entries.

Blockchains see consensus state.

Custody sees authorization artifacts.

Reconciliation sees delayed comparisons.

None of them sees the complete economic world.

A resilient platform therefore cannot treat incoming events as global truth.

It must treat them as evidence.

That evidence needs provenance, authority, timing, coverage, freshness, and domain semantics. Conflicting observations must remain visible. Silence must remain uncertainty unless the source can provide meaningful negative evidence. Historical decisions must preserve what the system knew at the moment they were made, not what later evidence revealed.

Most importantly, the system must separate estimation from permission.

The best estimate of reality may be enough for forecasting.

It may not be enough to release irreversible value.

Financial safety depends on knowing the difference.

A useful architecture therefore maintains three layers:

Evidence:
    what was actually observed

Belief:
    what the evidence justifies concluding

Permission:
    what the system is willing to risk based on that conclusion
Enter fullscreen mode Exit fullscreen mode

Collapse those layers and uncertainty becomes invisible.

Preserve them, and the system can continue operating even when external truth arrives late, incomplete, contradictory, or not at all.

A distributed financial system does not need omniscience.

It needs to know exactly what it does not know, and exactly how much economic authority it is willing to grant while that uncertainty remains.

Top comments (0)