From Event Observability to Epistemic Architecture
In classical deterministic systems, replay appears straightforward: an event enters a service, gets processed, output is reproducible. But reproducibility rests on fragile assumptions even in deterministic systems. A database changes. An API updates. Configuration shifts. Event order differs. Exact replay is often impossible, even deterministically.
In probabilistic systems, the structural difference is not that replay becomes impossible—it is that dimensionality of what must be preserved increases. Formally: D_t = f(E, S, C, M, R, T, ξ)—event, execution state, context, model, retrieved evidence, tools invoked, and uncontrolled variance.
Exact replay is not intrinsically impossible; it requires freezing enough of the execution environment—random seeds, runtime versions, model weights, corpus state, tool responses, hardware configuration—that residual variance becomes negligible. That preservation has cost.
The architectural reality: reproducibility cost increases with dimensionality. A novel dimension emerges: epistemic depth. You must preserve not just execution state and environment, but epistemic conditions under which the assertion was produced.
Therefore: exact replay becomes an economic choice, not a technical binary. The question is not “can we replay?” but “what level of reproducibility does this decision’s consequence justify?”
In classical systems, the unit of observability is the event. Event logs construct history.
In probabilistic systems, a new layer emerges: the assertion—a computation result carrying epistemic uncertainty. We must now distinguish carefully:
Event: What happened (input, trigger, message). Execution: How it was processed (conditions, computational path). Assertion: What was produced (result with epistemic status). Decision: What action was chosen (assertion + policy + authority).
Each answers distinct questions and carries distinct metadata. Event envelope captures what. Execution envelope captures how. Assertion envelope captures what result and with what epistemic status. Decision envelope captures what action with what authority.
This progression mirrors classical observability evolution: monitoring (Event) → observability (Assertion) → auditability (Decision with justification).
The critical insight: assertion is the epistemic unit. Decision is the operational unit. They must not be conflated.
Classical type systems encode structure (“this is a string”). Semantic typing added meaning (“this is a severity classification”). Epistemic typing now encodes how we know: “this severity was inferred by SafetyClassifier_V3.0 from cases [001,045] with confidence 0.78, valid for outpatient domain, expiring at T+90 days.”
Epistemic typing is an architectural discipline governing what epistemic statuses are permitted, what transformations are allowed between statuses, what operations require explicit policy gates, when assertions expire or lose validity.
Epistemic types are multidimensional: Origin × Method × TemporalStatus. Origin: Sensor, Human, Model, Policy, ExternalSource. Method: Observed, Derived, Inferred. TemporalStatus: Current, Predicted, Historical.
This avoids forcing false choices between INFERRED and PREDICTED—they are independent axes.
Epistemic typing enables formal transformation rules:
(Model, Inferred, Current) + [validation_by: Human] → (Human, Observed, Current) (Model, Inferred, Predicted) + [policy_gate: X] → (Policy, Derived, Predicted) Expired(assertion) → InvalidForDecision(assertion)
Critically: NO implicit transformation.
(Model, Inferred, Current) -/→ (Human, Observed, Current) [WITHOUT validation]
This rule prevents epistemic laundering—the unauthorized collapse of epistemic types. This is precisely what downstream systems do: a SafetyModel produces “Risk=HIGH, confidence=0.65, epistemic_status=INFERRED.” By the time it reaches Decision, only “Risk=HIGH” remains. The system believes this is observation. Assertion governance applies type checking at contract boundaries, preventing cascading loss of epistemic precision.
Epistemic status answers “how do we know this?” Authority answers “what is this information allowed to cause?” These are independent:
(Model, Inferred, Current) + authority: advisory → can inform recommendations (Model, Inferred, Current) + authority: executable → can trigger actions (higher risk)
Risk is multifactorial: Risk(assertion) = EpistemicRisk × AuthorityRisk × IrreversibilityRisk.
An epistemic assertion with zero authority poses no operational risk, regardless of uncertainty. The same assertion with executable authority becomes systemic.
Reproducibility is not binary. It is graduated:
Effect Idempotency: Does duplicate delivery create unintended duplicate effects? Classical problem. Cheap. Generally required.
Assertion Stability: Under the same frozen context (same model version, evidence, policy state), does assertion category remain stable? Magnitude may shift (confidence 0.78 to 0.82), classification (HIGH vs. LOW) remains. Moderate cost. Required for medium-risk decisions.
Execution Reproducibility: Can you obtain exactly the same assertion replaying all of (E, S, C, M, R, T)? Depends on uncontrolled variance. Expensive or impossible. Required only for high-risk or regulated decisions.
The architectural principle: buy the level of reproducibility justified by consequence. Expensive exactness is not required everywhere.
Event-Driven Architecture has benefits (asynchrony, resilience) and costs (order uncertainty, eventual consistency).
Probabilistic systems add a dimension: Ω_system = Ω_distributed × Ω_epistemic
The Cartesian product is multiplicatively larger. The resulting decision cannot be derived from events alone; it depends on both realized event order and epistemic state at execution.
The solution: assertion envelope plus versioned state snapshots at each agent. This enables temporal causality reconstruction—you can step through sequence and understand why each agent produced its assertion.
Governance Plane (Architecture of Authority): Capability → Decision Rights → Authority. Static or slowly-changing.
Execution Plane (Runtime Sequence): Event → Execution → Assertion → Decision → Effect. What happens at runtime.
These are orthogonal structures previously conflated. Governance answers “who decides?” Execution answers “what happens?”
Assertions inhabit both: in governance plane (“this assertion-type is assigned to this authority level”) and in execution plane (“this computation produced an assertion with this epistemic status”).
This separation resolves architectural ambiguity.
Epistemic contracts carry four dimensions: Assertion_value + Epistemic_type(origin, method, temporal) + Authority_boundary + Validity_conditions(domain, expiration, reversibility).
This transforms distributed systems from “services exchanging data” to “services exchanging assertions with traceable provenance and bounded authority.”
This applies far beyond agents: classical ML (model outputs with uncertainty), digital twins (simulations with predicted status), recommendation engines (scores with inferred status), autonomous systems (actions with authority levels), hybrid human-AI systems (mixing human assertions with machine inferences).
The common pattern: probabilistic computation produces assertions. Assertions must carry epistemic status and authority boundaries. Contracts must make this explicit.
Distributed systems with probabilistic components face a new architectural requirement: epistemic typing—ensuring every assertion carries conditions of credibility and authority boundaries.
The core principles:
Where assertions never collapse implicitly into facts, and authority is never assumed from technical capability alone.
This is what governance of probabilistic agents requires.
Doctrinal notes and explorations on AI in regulated systems. Once or twice a month. One-click unsubscribe.