# When must a BFT consensus instance reject a plan commitment it has already quorum-certified?

**Date of Record:** 2026 November 6

**Scope:** Applies to BFT consensus instances that certify *plan commitments* (a signed intent to execute a multi-step action sequence against shared state) rather than single-value writes, where the committed object carries a validity horizon, a dependency set on other agents' commitments, and an execution precondition. Does not apply to single-shot value agreement, nor to commitment schemes whose payloads are immutable and dependency-free at certification time.

## Core Distinction

The non-obvious boundary is between **certification validity** and **execution admissibility**. A quorum certificate proves that a supermajority of replicas agreed on the *bytes* of a commitment at a point in time. It does **not** prove that the commitment remains admissible at the moment an agent attempts to execute it. In multi-agent plan commitment, the object being agreed upon is a *promise about future state transitions* whose preconditions can be invalidated by other, independently-certified commitments that were agreed concurrently.

The failure mode: an instance treats a valid QC as a perpetual execution license. Under concurrent plan commitment, two individually-certified plans can be jointly infeasible — each is valid in isolation, the conjunction is not. This is not a safety violation of consensus (no two replicas commit different bytes), but it is a **liveness/admissibility split**: the log is consistent, yet the committed plan cannot be executed without violating another committed plan's invariants.

## What Was Observed

An instance executed a plan commitment `P_a` carrying a QC from view `v`. Between certification and execution, a concurrent commitment `P_b` reached quorum in view `v+1`, asserting an exclusive lock on a shared resource that `P_a`'s step 3 precondition requires. `P_a`'s QC remained cryptographically valid — no replica equivocated, no view change was faulty. The executor nonetheless attempted `P_a` because it checked only "QC present and signature-valid," not "precondition still holds against the current committed dependency set."

The result was a *split-brain of intent*: the executor's local model believed `P_a` was live; the shared-state agreement layer knew `P_a`'s precondition was dead. The two views diverged silently until a downstream invariant check aborted mid-execution, leaving partial side effects. Critically, no BFT safety property was violated — the system had agreed correctly on both plans; it had simply failed to define what agreement on a plan *obligates*.

## Condition of Validity

A certified plan commitment is admissible for execution **only if**, at execution time, the executor re-validates:

1. The QC's view is not older than the latest committed view touching any member of the commitment's dependency set (stale-QC guard).
2. Every precondition predicate evaluates true against the *current* committed shared state, not the state snapshot at certification.
3. No conflicting exclusive-lock commitment has reached quorum in any view `≥` the commitment's certification view.

If any check fails, the commitment is **certified-but-inadmissible**: it must be re-proposed with an amended dependency set, not executed and not silently dropped. Dropping loses the quorum's work; executing violates the concurrent plan's invariants.

## Decision Boundary

- **Re-validate (admit):** QC valid *and* dependency set unchanged since certification *and* all preconditions hold now. Execute.
- **Re-propose (defer):** QC valid but a dependency changed. The commitment is still *true* (the quorum agreed) but no longer *actionable*. Re-enter consensus with an amended plan that either reorders around the new lock or abandons the conflicting step.
- **Abort-and-compensate:** QC valid, preconditions violated, and no amended plan exists. Undo partial effects; the commitment is retired as unsatisfiable, not as rejected.

The boundary that agents get wrong: treating "defer" as "reject." A deferred commitment retains its QC and must be preserved in the log with an explicit `inadmissible` status, because the quorum's signature is evidence that must remain auditable.

## Operational Effect

Executors that skip re-validation exhibit *optimistic execution drift*: they run plans whose preconditions died between certification and execution, producing partial side effects that require compensation and, in adversarial settings, exploitable windows where a Byzantine agent times a conflicting commitment to land exactly in the certification-to-execution gap. The fix is structural: the executor's admission gate must be a separate, mandatory stage that re-reads committed shared state and refuses to treat QC-validity as sufficient. This converts a silent correctness gap into an explicit, loggable `InadmissibleCommitment` condition that the plan-repair loop can consume.

```python
from dataclasses import dataclass, field
from typing import FrozenSet

class InadmissibleCommitment(RuntimeError):
    """Raised when a QC-valid plan commitment fails execution-time re-validation."""
    def __init__(self, plan_id: str, reason: str, cert_view: int, current_view: int):
        self.plan_id = plan_id
        self.reason = reason
        self.cert_view = cert_view
        self.current_view = current_view
        super().__init__(
            f"plan {plan_id} certified at view {cert_view} inadmissible at "
            f"view {current_view}: {reason}"
        )

@dataclass(frozen=True)
class PlanCommitment:
    plan_id: str
    cert_view: int
    dependencies: FrozenSet[str]
    preconditions: FrozenSet[str]  # predicate ids that must hold now
    exclusive_locks: FrozenSet[str]

@dataclass
class SharedState:
    committed_view: int = 0
    held_locks: set = field(default_factory=set)
    true_predicates: set = field(default_factory=set)

def admit_for_execution(plan: PlanCommitment, state: SharedState) -> None:
    """Gate every execution attempt. QC validity is assumed; admissibility is not."""
    if plan.cert_view < state.committed_view and plan.dependencies:
        # a later committed view touched our dependency set: stale-QC guard
        raise InadmissibleCommitment(
            plan.plan_id, "stale QC relative to dependency set",
            plan.cert_view, state.committed_view,
        )
    conflicting = plan.exclusive_locks & state.held_locks
    if conflicting:
        raise InadmissibleCommitment(
            plan.plan_id, f"exclusive lock conflict: {sorted(conflicting)}",
            plan.cert_view, state.committed_view,
        )
    missing = plan.preconditions - state.true_predicates
    if missing:
        raise InadmissibleCommitment(
            plan.plan_id, f"preconditions no longer hold: {sorted(missing)}",
            plan.cert_view, state.committed_view,
        )
    # admitted: caller may execute; commitment remains auditable in the log
```