The estate is a stack of clocks, not a map of boxes

A conventional architecture diagram makes a bank look spatial. Channels sit at the top, services in the middle, cores and data platforms below. Lines show connectivity. That view is useful for ownership and traffic, yet it hides the property that most strongly constrains automation: each layer changes state according to a different clock and a different definition of completion.

A mobile channel may respond in hundreds of milliseconds. An API gateway may acknowledge a request before downstream work begins. A transactional core may commit a local unit of work immediately. An enterprise batch scheduler may wait for a class, dependency or cut-off. A payment instruction may remain revocable until a defined point of finality. A warehouse may reconstruct the position several hours later. A human operations queue may be the only place where an exception is resolved.

A banking day is therefore a temporal topology. Its important edges carry more than messages. They carry freshness loss, authority changes, transaction boundaries, cut-off rules, reconciliation obligations and uncertainty about whether an effect happened. An agent connected to every component still does not possess a single present moment.

Four times that architecture diagrams usually collapse

The opening case becomes tractable when “time” is separated into four quantities. Interaction time is when the customer or colleague expresses intent. Commit time is when a system makes a durable local state change. Propagation time is when copies, events and dependent systems become consistent enough for their purpose. Business-finality time is when the institution may legitimately treat the outcome as complete or no longer revocable.

These times may be almost identical for a low-risk profile preference and hours apart for a cross-system financial process. The international Principles for Financial Market Infrastructures explicitly require the point of settlement finality to be defined. That principle concerns financial market infrastructures, not every internal workflow, but it exposes a general design error: a receipt from one technical layer does not establish the terminal business state.

Authority is also layered

Time alone does not identify the right source. A bank seldom has one universally authoritative database. The identity service may be authoritative for the authenticated subject. The product core may be authoritative for account status. A card processor may be authoritative for whether a card is blocked. A case-management system may be authoritative for an investigator’s disposition. A ledger or payment infrastructure may define whether value moved.

A warehouse, search index or vector store can be the best place to discover evidence without being entitled to authorise an effect. This distinction matters because agent platforms often optimise retrieval first. They make more information visible, then permit the model to act from the assembled context. The resulting context may be informative yet temporally stale, derived, policy-filtered for another purpose or detached from the system that owns the transition.

Data boundaries are part of the mechanism

An agent may have technical connectivity to a source and still lack a permitted path for this subject, purpose or decision. Customer data retrieved for service may not be reusable for marketing. An investigator may see restricted evidence that a front-office assistant must not receive. A model-generated explanation may combine facts whose individual entitlements do not survive aggregation.

The control cannot live only in the prompt. Entitlement must be evaluated before retrieval, preserved in the context envelope and checked again before effect. The evidence ledger should record which source supported which claim and under what purpose. If a long-running workflow resumes after a role, consent or policy change, the permission decision must be refreshed. Authority and data applicability are temporal state, not static configuration.

This is another way the estate sets the frontier. A perfect answer derived from an impermissible source cannot be released. A technically valid action executed after its purpose has expired is still unauthorised. The boundary is therefore shaped by identity systems, policy decision points and data-lineage services as much as by cores and batches.

Thought experiment: move only the commit boundary

Give the same agent the same customer request, prompt, tool schema and policy. In Estate A, the cancellation tool invokes a CICS transaction whose unit of work either commits or rolls back, returns a stable transaction identifier and supports an immediate authoritative readback. In Estate B, the tool writes a row to a staging table that an overnight job may process. Both interfaces return success when their local write completes.

Nothing about the model has changed. In Estate A, bounded automation may be possible if the readback confirms the postcondition and the action is otherwise authorised. In Estate B, the agent may submit the request, but it cannot truthfully promise the final effect before the job runs. The permitted release changes from “execute and confirm” to “queue and report pending”.

Changing one estate property moves the automation frontier without changing intelligence. This is the causal intervention the article relies on. The same reasoning process supports different operational claims because the systems expose different evidence.

Age is a poor proxy for controllability

The word “legacy” often bundles several problems: end-of-life components, scarce skills, weak interfaces, slow change, opaque dependencies and old security assumptions. Those are real risks. The EU Digital Operational Resilience Act explicitly calls for risk assessment of legacy ICT systems and of connections between technologies and applications. Yet age does not tell us whether one action is atomic, observable or recoverable.

A well-run mainframe transaction can have a crisp unit-of-work boundary, mature recovery semantics and decades of operational evidence. A cloud-native chain can contain five services, three queues, eventual consistency, duplicated messages and no independent confirmation of the customer outcome. The first may be old and controllable. The second may be new and ambiguous. The useful question is not “Is this modern?” It is “What can this path prove under failure?”

flowchart LR
  A["The cancellation that was true<br/>in three different ways"] --> B["The estate is a stack of<br/>clocks, not a map of boxes"]
  B --> C["The frontier is a proof corridor"]
  C --> D["Three controlled cases"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#7B4CD8,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

The frontier is a proof corridor

Model evaluation and estate evaluation answer different questions. Model evaluation asks whether a configured proposal mechanism performs the intellectual task well enough: interpreting the request, extracting fields, selecting a policy branch or forming a recommendation. Estate evaluation asks whether a correct proposal can be converted into exactly the intended effect, under current authority, with evidence strong enough to release the outcome.

The two evaluations meet in a simple release rule. Let s be one workflow step. Let Q(s) mean that the proposal mechanism has passed its task-level quality gate. Let F mean fresh authoritative state, A bounded authority, I idempotent or duplicate-detectable execution, O independent outcome observation before the harm deadline, C compensation or controlled recovery, and D permitted, attributable data movement.

This is a practitioner decision rule, not a scientific law. It does not claim that every institution must implement identical controls. Its value is causal clarity. It prevents an aggregate risk score from allowing strength in one dimension to offset an absence in another. A 99.9 per cent model score does not authorise an action. A perfect API contract does not make stale evidence current. A human approval does not cure a retry that can debit twice.

Accepted, committed, observed and final are different receipts

A useful control plane gives names to the milestones it can actually establish. An acceptance receipt proves that an interface received and admitted a request. A commit receipt proves that a specified transactional boundary made a durable change. An effect receipt records what the execution component claims it changed. A readback receipt records an independent observation of the postcondition. A business-outcome receipt ties the technical state to the operational result that matters, such as a blocked card, a cancelled instruction or a settled payment.

These receipts need not become separate documents. They can be fields in one decision ledger. What matters is that the interface does not collapse them into one boolean called success. That boolean is the place where queues masquerade as completion and local writes masquerade as customer outcomes.

The end-to-end argument in systems design explains why lower-layer assurance can be insufficient for an application-level goal. A reliable message transport cannot prove that the business operation completed correctly. The application must check the end condition it cares about. In an agentic banking workflow, that means outcome verification belongs outside the model and, where possible, outside the same execution response path.

The unknown outcome is the decisive failure mode

Suppose a tool call times out after the target system has committed the change but before the response reaches the orchestrator. Retrying may duplicate the effect. Avoiding a retry may leave the work incomplete. Asking the model to infer what probably happened adds language to an epistemic gap. The system does not know.

Idempotent APIs reduce this ambiguity by binding retries to a caller-supplied operation identity. Duplicate-detectable interfaces can also help when true idempotence is unavailable, provided the deduplication key survives restarts and spans the actual effect boundary. The key must represent the customer’s intended operation, not merely the text of the request. Two identical transfers may be two genuine intentions, while two differently formatted retries may be one intention.

Apache Kafka’s documentation is instructive here. Its idempotent and transactional guarantees have explicit scopes, and its design notes warn that “exactly once” claims require careful reading. A message appearing once in a topic does not establish that an external core, card processor or payment rail applied a business effect once. Exactly-once business outcome is an end-to-end property, assembled from local guarantees and independent observation.

Compensation preserves intent, not history

Many banking workflows cross boundaries that cannot share one atomic transaction. The classic saga formulation breaks a long-lived transaction into local transactions with compensating actions for partial execution. This remains useful, but compensation is frequently misunderstood as rollback. It is a new business action performed in a world that may have changed.

If a card replacement order is cancelled after a card number has already been issued, the compensation may mark the issued card unusable and create an exception. It does not erase every event that observed the temporary state. If a fee is refunded, the refund does not make the original debit historically nonexistent. If a payment entered a rail beyond its revocation point, a new return or recovery process may be required.

Pat Helland’s account of large systems places uncertainty in workflow semantics when distributed transactions are unavailable. That is precisely the situation an agent runtime must expose. It should represent pending, unknown, compensating and reconciled as first-class states. A fluent assistant should never smooth them into “done”.

Thought experiment: add only an outcome observer

Return to Estate B, where the cancellation is queued for batch. Keep the model, queue and core unchanged. Add a service that watches the authoritative batch result, correlates it with the request identifier and emits either cancelled, too_late or exception before the next customer commitment. The orchestrator persists the pending state and resumes when the observation arrives.

The agent still cannot make the cancellation happen sooner. It can now make a stronger promise: “Your request has been submitted. I will confirm the result before 09:00.” When the observer records the postcondition, the workflow can notify the customer or route an exception. The automation frontier has moved from manual reconciliation towards durable, bounded execution, even though no model parameter changed.

This thought experiment separates speed from controllability. Automation does not require every system to become synchronous. It requires the workflow to represent delay honestly, preserve identity across the delay and obtain evidence before making the consequential claim.

The strongest objection: many useful tasks never cross this frontier

A critic can reasonably argue that model capability often is the binding constraint. Drafting a customer-friendly explanation from approved policy, classifying an internal message or summarising a reconciled case may create value without changing a system of record. For these tasks, better reasoning, grounding and calibration can expand useful automation even when the underlying core remains untouched.

That objection is correct and marks the scope of the claim. The estate thesis concerns effectful automation and any customer-facing assertion that depends on current operational state. It does not say that every AI task is limited by transaction semantics. An informational task can sit largely above the action frontier, although data entitlement and freshness still apply.

The competing explanation becomes inadequate when an output initiates, confirms or materially shapes a consequential state transition. At that point, model quality remains necessary but no longer sufficient. More accurate reasoning can reduce wrong proposals; it cannot observe a hidden commit, make a duplicate retry harmless or create settlement finality. The useful distinction is between a proposal frontier and an action frontier, not one universal bottleneck.

Three controlled cases

The frontier should be assessed at the granularity of one consequential state transition. “Automate card servicing” is too coarse. The journey may include understanding a narrative, authenticating a customer, freezing a card, ordering a replacement, updating a wallet token, notifying the customer and opening a dispute. Each step has a different state owner, clock, reversibility and proof path.

Minimal worked example: switch to paperless statements

Consider a verified customer who asks to stop paper statements. The model’s job is modest: interpret the request and extract the account scope. The deterministic path binds the authenticated customer, checks that the account is eligible, reads the current preference from the authoritative profile service and invokes a typed change operation with an idempotency key.

The profile service commits the new value and returns an operation identifier. A separate read endpoint confirms the postcondition within seconds. The customer can reverse the preference later, and a failed notification does not alter the preference itself. Under these assumptions, every hard estate gate can pass. The assistant may execute and confirm.

Now vary one feature. Replace the authoritative read with a six-hour-old warehouse replica. The request and model output remain identical. The assistant no longer knows whether a colleague or another channel has already changed the preference. It can still explain how to change it, but it should not issue a mutating action from that view. The same apparently simple task crosses the frontier when freshness and authority change.

Production-shaped example: a compromised debit card

A customer reports an unfamiliar card transaction. The journey begins as one conversation but should split into separate state transitions. The model may summarise the account, identify that the customer wants the card protected and propose the relevant product procedure. It should not inherit the customer’s execution authority merely because it understood the narrative.

First, the channel performs strong authentication and binds the customer’s explicit purpose. Second, the card service reads current card status and any existing block from its authoritative source. Third, a deterministic authority kernel decides whether the verified instruction permits a freeze. If the freeze endpoint is idempotent and supports immediate independent readback, the step can be auto-executable. Freezing is protective and reversible, though local policy still sets the threshold.

Replacement is a different step. The card processor may accept an order that enters an overnight fulfilment cycle. The system may not expose a reliable readback before the customer expects confirmation. The assistant can submit the order and say “requested”, but should withhold “your replacement has been issued” until an effect receipt arrives. If a duplicate order is possible, the workflow needs durable deduplication or a controlled queue.

The unfamiliar transaction is different again. Opening a dispute, crediting funds, making a fraud determination and filing a regulatory report can involve distinct policy and accountable-decision boundaries. The model can assemble evidence and draft a case. A deterministic calculation can compute amounts. A human or authorised rule may own the final disposition. One journey can legitimately span every release mode.

Negative control: modern services without a stronger outcome

A fair causal argument needs a case where the preferred explanation looks unnecessary. Imagine replacing a mainframe interaction with a new microservice façade. The new service exposes REST, runs in containers and emits events. The user experience becomes faster. Yet the service acknowledges before the core applies the change, retries are not deduplicated end to end and the event stream reports the façade’s local state rather than the core postcondition.

The technology is modern, but the proof corridor has not improved. The agent can call a cleaner interface and fail more elegantly. Its safe release mode remains “request submitted”. By contrast, an older transaction path with a clear unit of work, operation identity, deterministic authorisation and independent readback may support “completed”.

This negative control weakens the simplistic claim that legacy systems set the frontier merely because they are old. The causal variables are narrower: state authority, temporal fit, transaction scope, effect observability and recovery. Modernisation is valuable when it improves those variables or reduces the cost of doing so.

stateDiagram-v2
  [*] --> Claim
  state "Four times that architecture<br/>diagrams usually collapse" as Claim
  state "Authority is also layered" as Test
  state "Data boundaries are part of<br/>the mechanism" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Assessing and moving the frontier

The practical mistake is to begin with an application inventory or a catalogue of agent use cases. A bank should begin with an important business service, the customer or market outcome it must continue to deliver and the impact tolerance within which disruption must be contained. It should then decompose the service into consequential state transitions.

For each transition, the assessment asks six estate questions and one model question. The model question is whether the proposal mechanism has earned its task-level quality claim under representative and adversarial cases. The estate questions are whether the system can establish fresh state, current authority, single-intent execution, timely outcome observation, controlled recovery and permitted data movement.

Step 1: name the business postcondition

“Call the card API” is an implementation instruction. “The specified card is blocked for authorisation attempts” is a postcondition. “Write the cancellation table” is an implementation instruction. “The instruction will not enter the next eligible payment cycle” is a postcondition. The assessment starts with the latter because it is what the customer and control owner care about.

The postcondition should include scope, effective time and denominator. “All cards” differs from “physical card ending 1234”. “Now” differs from “before the next rail cut-off”. “Notification sent” differs from “customer received notification”. Precision reveals which system can testify to the outcome.

Step 2: locate state and authority at effect time

Record the authoritative read source, the maximum acceptable age of that observation and the decision horizon. A current account balance used to calculate a fee may tolerate seconds. A monthly marketing preference might tolerate minutes. A sanctions or fraud control may require a policy-defined freshness condition. The threshold is a business and control decision, not an architecture default.

Then bind actor, subject, purpose and action. The user requested the change; the model proposed parameters; the authority kernel decided whether the proposed effect was permitted; the system credential executed it. Preserving these principals prevents an agent from becoming a confused deputy that spends ambient service authority on behalf of an insufficiently authenticated request.

Step 3: inject the failures that create false completion

Happy-path demonstrations systematically overstate the frontier. The assessment should force the states that ordinary testing avoids. Make the read source stale, change policy between proposal and execution, time out after commit and deliver the same event twice. Let a batch cut-off pass during approval, a third party accept and later reject, an outcome event disappear, a compensation fail or an entitlement expire while the case is pending.

Each injection should produce a typed state and an owned next action. unknown_outcome should initiate readback or reconciliation, not prompt improvisation. authority_expired should require a fresh decision. duplicate_detected should return the prior effect receipt. compensation_failed should create an operational exception with the evidence needed to resolve it.

Step 4: assign one of four release modes

Step 5: modernise the missing proof link

An estate assessment is useful only if it changes investment. If freshness fails, build a controlled event or change-data-capture path, or read the authoritative source at decision time. If duplicate control fails, add an operation identity and durable deduplication at the effect boundary. If observation fails, add readback or a reconciled outcome event. If recovery fails, design compensation and an owned exception queue. If authority fails, place a deterministic policy and identity gate in front of the action.

This reframes legacy modernisation. The target is not an abstract percentage of cloud adoption. The target is a smaller set of unprovable transitions in important business services. A core replacement may be justified, but an outcome adapter, a typed façade, a bitemporal state view or an event bridge may move the frontier sooner and with less migration risk. The assessment makes that trade visible.

#!/usr/bin/env python3
"""Assess whether a banking workflow step is eligible for bounded automation.

The tool uses synthetic inputs only. It is a decision aid, not a regulatory model.
Run:
    python banking_estate_frontier_assessment.py
"""

from __future__ import annotations

from dataclasses import dataclass
from enum import Enum
from typing import Iterable, Optional


class Consequence(str, Enum):
    LOW = "low"
    MATERIAL = "material"
    IRREVERSIBLE = "irreversible"


class Deduplication(str, Enum):
    IDEMPOTENT = "idempotent"
    DUPLICATE_DETECTABLE = "duplicate-detectable"
    NONE = "none"


class Compensation(str, Enum):
    AUTOMATIC = "automatic"
    MANUAL = "manual"
    NONE = "none"


class Decision(str, Enum):
    AUTO_EXECUTE = "AUTO_EXECUTE"
    APPROVAL_REQUIRED = "APPROVAL_REQUIRED"
    WRAP_OR_QUEUE = "WRAP_OR_QUEUE"
    ADVISE_ONLY = "ADVISE_ONLY"


@dataclass(frozen=True)
class WorkflowStep:
    name: str
    consequence: Consequence
    decision_horizon_s: int
    authoritative_read: bool
    observed_state_age_s: Optional[int]
    typed_action_contract: bool
    identity_and_purpose_bound: bool
    deduplication: Deduplication
    independent_readback: bool
    readback_sla_s: Optional[int]
    harm_deadline_s: int
    compensation: Compensation
    permitted_data_path: bool
    human_approval_available: bool

    def validate(self) -> None:
        if self.decision_horizon_s <= 0:
            raise ValueError(f"{self.name}: decision_horizon_s must be positive")
        if self.harm_deadline_s <= 0:
            raise ValueError(f"{self.name}: harm_deadline_s must be positive")
        if self.observed_state_age_s is not None and self.observed_state_age_s < 0:
            raise ValueError(f"{self.name}: observed_state_age_s cannot be negative")
        if self.readback_sla_s is not None and self.readback_sla_s < 0:
            raise ValueError(f"{self.name}: readback_sla_s cannot be negative")


@dataclass(frozen=True)
class Assessment:
    step: WorkflowStep
    decision: Decision
    failed_gates: tuple[str, ...]
    rationale: str


def _fresh(step: WorkflowStep) -> bool:
    return (
        step.authoritative_read
        and step.observed_state_age_s is not None
        and step.observed_state_age_s <= step.decision_horizon_s
    )


def _observable_before_harm(step: WorkflowStep) -> bool:
    return (
        step.independent_readback
        and step.readback_sla_s is not None
        and step.readback_sla_s <= step.harm_deadline_s
    )


def assess(step: WorkflowStep) -> Assessment:
    """Return a release decision from hard evidence gates.

    Model accuracy is deliberately outside this function. A workflow should call this
    only after the proposal mechanism has separately met its task-level quality bar.
    """

    step.validate()

    foundational_failures: list[str] = []
    if not step.authoritative_read:
        foundational_failures.append("no authoritative read path")
    elif not _fresh(step):
        foundational_failures.append("state is older than the decision horizon")
    if not step.permitted_data_path:
        foundational_failures.append("data path is not permitted or attributable")
    if not step.typed_action_contract:
        foundational_failures.append("action interface is not typed")
    if not step.identity_and_purpose_bound:
        foundational_failures.append("identity and purpose are not bound at execution")

    if foundational_failures:
        return Assessment(
            step=step,
            decision=Decision.ADVISE_ONLY,
            failed_gates=tuple(foundational_failures),
            rationale=(
                "The step lacks evidence needed to know the applicable state or to "
                "authorise a specific effect. Keep the model advisory until the missing "
                "contract or authoritative path exists."
            ),
        )

    effect_failures: list[str] = []
    if step.deduplication is Deduplication.NONE:
        effect_failures.append("retry can duplicate the effect")
    if not _observable_before_harm(step):
        effect_failures.append("postcondition cannot be read back before the harm deadline")
    if step.compensation is Compensation.NONE and step.consequence is not Consequence.LOW:
        effect_failures.append("no compensation or controlled recovery path")

    if effect_failures:
        return Assessment(
            step=step,
            decision=Decision.WRAP_OR_QUEUE,
            failed_gates=tuple(effect_failures),
            rationale=(
                "Intent and authority are available, but execution can enter an unknown "
                "or duplicate state. Add an idempotency facade, outcome observer, durable "
                "queue or reconciliation control before releasing autonomous execution."
            ),
        )

    needs_approval = (
        step.consequence is Consequence.IRREVERSIBLE
        or step.compensation is Compensation.MANUAL
    )
    if needs_approval:
        if not step.human_approval_available:
            return Assessment(
                step=step,
                decision=Decision.ADVISE_ONLY,
                failed_gates=("required accountable approval is unavailable",),
                rationale=(
                    "The estate can prove the effect, but the consequence or recovery model "
                    "requires an accountable approver. Without that role, remain advisory."
                ),
            )
        return Assessment(
            step=step,
            decision=Decision.APPROVAL_REQUIRED,
            failed_gates=(),
            rationale=(
                "The evidence corridor is complete, but consequence or manual recovery "
                "requires approval before the deterministic authority kernel executes."
            ),
        )

    return Assessment(
        step=step,
        decision=Decision.AUTO_EXECUTE,
        failed_gates=(),
        rationale=(
            "Fresh authoritative state, bounded authority, duplicate control, timely "
            "readback, permitted data movement and recovery evidence are all present."
        ),
    )


def synthetic_steps() -> tuple[WorkflowStep, ...]:
    """Positive and negative cases used in the article."""

    return (
        WorkflowStep(
            name="Verified paperless-statement preference",
            consequence=Consequence.LOW,
            decision_horizon_s=300,
            authoritative_read=True,
            observed_state_age_s=8,
            typed_action_contract=True,
            identity_and_purpose_bound=True,
            deduplication=Deduplication.IDEMPOTENT,
            independent_readback=True,
            readback_sla_s=3,
            harm_deadline_s=300,
            compensation=Compensation.AUTOMATIC,
            permitted_data_path=True,
            human_approval_available=True,
        ),
        WorkflowStep(
            name="Freeze card after verified customer instruction",
            consequence=Consequence.MATERIAL,
            decision_horizon_s=30,
            authoritative_read=True,
            observed_state_age_s=2,
            typed_action_contract=True,
            identity_and_purpose_bound=True,
            deduplication=Deduplication.IDEMPOTENT,
            independent_readback=True,
            readback_sla_s=4,
            harm_deadline_s=30,
            compensation=Compensation.AUTOMATIC,
            permitted_data_path=True,
            human_approval_available=True,
        ),
        WorkflowStep(
            name="Create replacement card through overnight batch",
            consequence=Consequence.MATERIAL,
            decision_horizon_s=300,
            authoritative_read=True,
            observed_state_age_s=20,
            typed_action_contract=True,
            identity_and_purpose_bound=True,
            deduplication=Deduplication.DUPLICATE_DETECTABLE,
            independent_readback=False,
            readback_sla_s=None,
            harm_deadline_s=900,
            compensation=Compensation.MANUAL,
            permitted_data_path=True,
            human_approval_available=True,
        ),
        WorkflowStep(
            name="Close a business current account",
            consequence=Consequence.IRREVERSIBLE,
            decision_horizon_s=120,
            authoritative_read=True,
            observed_state_age_s=5,
            typed_action_contract=True,
            identity_and_purpose_bound=True,
            deduplication=Deduplication.IDEMPOTENT,
            independent_readback=True,
            readback_sla_s=10,
            harm_deadline_s=120,
            compensation=Compensation.MANUAL,
            permitted_data_path=True,
            human_approval_available=True,
        ),
        WorkflowStep(
            name="Change address from a six-hour warehouse replica",
            consequence=Consequence.MATERIAL,
            decision_horizon_s=300,
            authoritative_read=False,
            observed_state_age_s=21_600,
            typed_action_contract=False,
            identity_and_purpose_bound=False,
            deduplication=Deduplication.NONE,
            independent_readback=False,
            readback_sla_s=None,
            harm_deadline_s=600,
            compensation=Compensation.NONE,
            permitted_data_path=True,
            human_approval_available=True,
        ),
    )


def render_markdown(assessments: Iterable[Assessment]) -> str:
    rows = [
        "| Workflow step | Decision | Failed evidence gates |",
        "|---|---|---|",
    ]
    for result in assessments:
        failures = "; ".join(result.failed_gates) if result.failed_gates else "None"
        rows.append(
            f"| {result.step.name} | {result.decision.value} | {failures} |"
        )
    return "\n".join(rows)


def main() -> None:
    results = tuple(assess(step) for step in synthetic_steps())

    expected = (
        Decision.AUTO_EXECUTE,
        Decision.AUTO_EXECUTE,
        Decision.WRAP_OR_QUEUE,
        Decision.APPROVAL_REQUIRED,
        Decision.ADVISE_ONLY,
    )
    observed = tuple(result.decision for result in results)
    assert observed == expected, (observed, expected)

    print("Synthetic banking-estate frontier assessment")
    print("Model proposal quality is assumed to have passed a separate release gate.\n")
    print(render_markdown(results))
    print("\nAll positive and negative case assertions passed.")


if __name__ == "__main__":
    main()

Synthetic banking-estate frontier assessment
Model proposal quality is assumed to have passed a separate release gate.

| Workflow step | Decision | Failed evidence gates |
|---|---|---|
| Verified paperless-statement preference | AUTO_EXECUTE | None |
| Freeze card after verified customer instruction | AUTO_EXECUTE | None |
| Create replacement card through overnight batch | WRAP_OR_QUEUE | postcondition cannot be read back before the harm deadline |
| Close a business current account | APPROVAL_REQUIRED | None |
| Change address from a six-hour warehouse replica | ADVISE_ONLY | no authoritative read path; action interface is not typed; identity and purpose are not bound at execution |

All positive and negative case assertions passed.

What would weaken the thesis?

The article’s claim is testable. Sample comparable workflow steps across several banking estates. Hold task definition, consequence policy and proposal quality as constant as practical. Measure safe auto-execution coverage, unknown-outcome incidents, duplicate effects, reconciliation load and customer-correction rates. Then test whether estate variables such as authoritative freshness, idempotency, readback latency and recovery completeness explain the release boundary.

If model benchmark improvements predict safe action coverage after those estate variables are controlled, while estate improvements add little, the thesis weakens. If modernising interface style moves the frontier without changing transaction or observation semantics, the negative control fails. If human review reliably resolves unknown outcomes without a stronger evidence path, the stated boundary is too strict.