Business State Estimation

World signals are observations, not world state. A payment callback may indicate that a payment succeeded, but “funds are settled and available” may require reconciliation. A customer complaint is evidence of dissatisfaction, but it does not by itself establish a general product trend.

In robotics, state estimation separates noisy sensor measurements from the robot’s current belief about itself and its environment. Probabilistic robotics represents uncertainty explicitly instead of committing immediately to one interpretation of incomplete or ambiguous data. See Sebastian Thrun’s Probabilistic Algorithms in Robotics and Probabilistic Robotics by Thrun, Wolfram Burgard, and Dieter Fox.

An autonomous business unit needs the same conceptual boundary. Its state estimator combines governed observations, prior state, and known actions into the best currently supported account of conditions relevant to its goals and authority.

From observation to estimated state

flowchart LR
    raw["Raw world signal"] --> observation["Validated observation"]
    observation --> estimate["Estimated business state"]
    prior["Prior state and known actions"] --> estimate
    estimate --> condition["Decision-relevant condition"]
    condition --> trigger["Trigger evaluation"]

The distinction creates four separate artifacts:

1. Raw signal: the original evidence received from a source.
2. Validated observation: the normalized claim, with provenance and access controls.
3. Estimated state: the unit’s current interpretation after considering other evidence and prior state.
4. Trigger condition: a policy expression that determines whether the estimated change requires work.

Keeping these artifacts separate prevents the latest event from silently replacing the unit’s model of reality.

The state-estimate contract

A consequential state estimate should record:

• Subject: the entity, account, obligation, goal, or capability being described.
• Claim: the condition currently believed to be true.
• Supporting observations: the evidence that supports the claim.
• Conflicting observations: relevant evidence that does not agree.
• Confidence or assurance level: how strongly the available evidence supports the claim.
• Effective time: when the condition is believed to have become true.
• Last validation time: when the estimate was last checked against an authoritative source.
• Expiry or revalidation rule: when the estimate becomes too stale to justify action.
• Derivation: the deterministic rule, model, agent, or authority that produced the estimate.
• Permitted uses: which decisions may rely on this level of evidence.

Not every estimate needs a numeric probability. The system may use assurance classes such as unverified, single-source, corroborated, authoritative, disputed, or expired. What matters is that uncertainty and evidence quality remain explicit.

Conflicting, delayed, and adversarial observations

Business systems rarely provide one perfectly ordered truth stream. A later event may describe an earlier occurrence. Two systems may disagree because they use different definitions or update schedules. A source may be compromised or may benefit from causing the unit to adopt a false state.

The estimator should therefore define:

• source precedence and corroboration rules
• event-time rather than arrival-time ordering where possible
• reconciliation for authoritative systems of record
• conditions that mark an estimate disputed
• retraction and correction behavior
• escalation when the evidence cannot support a consequential decision

An agent may help interpret ambiguous evidence, but it must not erase disagreement or manufacture confidence. Its conclusion should remain linked to the observations and assumptions from which it was derived.

Trigger on meaningful state change

The unit should not invoke an agent or workflow for every received event. It should trigger when a decision-relevant condition changes. Event-triggered control in robotics similarly schedules computation from system state rather than continuously running every possible control task. Paulo Tabuada’s Event-Triggered Real-Time Scheduling of Stabilizing Control Tasks develops this principle for physical control systems.

Business triggers can use:

• thresholds and target ranges
• persistence windows that require a condition to remain true
• hysteresis so a value near a boundary does not repeatedly toggle state
• cooldowns and rate limits
• aggregation across related observations
• change magnitude or novelty
• deadlines and expiry
• confidence or assurance requirements

The mathematical stability guarantees of physical control do not automatically transfer to a business. The transferable principle is that scheduling should respond to meaningful estimated state, not blindly to event volume.

State is governed context

Estimated business state is durable organisational or unit context. A workflow resolves the relevant subset into task context only when a trigger creates or resumes work. This prevents the full event history or business state from being copied into every prompt.

Changes to an estimate should be versioned and attributable. The execution ledger should record which state version and evidence justified a trigger, so a later reviewer can reconstruct why the unit acted even if the estimate subsequently changed.

Related concepts

• World Signals - Supplies authenticated and normalized observations.
• Workflow Engine - Evaluates trigger conditions and preserves execution across time.
• Context Layers - Determines how state reaches the responsible agent or workflow.
• Business Unit Goals - Defines which conditions count as progress, failure, or risk.
• Execution Ledger - Records the evidence and state version behind a decision.