Rebuttal Recall Arbitration / 反驳召回仲裁

Rebuttal Recall Arbitration is an assignable rite for choosing which correction binds first when 反驳召回撞锁案卷 is open.

It exists because neither recall nor rebuttal should be magic. A recall can stop a stale floor order while still denying the affected party a response. A rebuttal can make a cited row answerable while the old cutroom mark still travels. The rite makes that collision a management/RPG decision with handlers, carriers, proof, acknowledgement, and future route consequences.

Offer conditions

Offer this rite when all are true:

offer_state:
  trigger_kind: state_pressure
  collision_docket_present: storyteller.card.rebuttal_recall_collision_docket.v1
  stale_dispatch_side_live_or_explicit_absence: true
  rebuttal_side_live_or_explicit_absence: true
  shared_authority_row_present: true
  future_reader_present: true
  stale_holder_or_explicit_absence_present: true
  affected_party_or_explicit_absence_present: true
  player_can_assign_binding_order: true
  no_fixed_turn_trigger: true
  no_fixed_day_or_week_trigger: true
  no_raw_count_trigger: true

Required assignment slots

A playable rite instance must expose these slots. A slot may be filled by explicit absence only when that absence changes the branch result.

rite_id: storyteller.rite.rebuttal_recall_arbitration.v1
assignments:
  collision_docket: storyteller.card.rebuttal_recall_collision_docket.v1
  shared_authority_row: <row id>
  stale_docket_or_absence: storyteller.card.stale_dispatch_docket.v1 | explicit_absence | equivalent
  rebuttal_ledger_or_absence: storyteller.card.reader_rebuttal_notice_ledger.v1 | explicit_absence | equivalent
  arbitrator_or_absence: han_yanshuang | shen_luo | yu_lan | baiya | ruan_chi | lin_qiao | ai_sheng | inspector | archive_clerk | sponsor_proxy | explicit_absence | equivalent
  stale_holder_or_absence: <holder or explicit_absence>
  affected_party_or_absence: <party proxy constituency or explicit_absence>
  carrier_or_absence: ruan_chi | lin_qiao | yu_lan | baiya | lawful_notice | public_line | runner_relay | explicit_absence | equivalent
  selected_binding_order: recall_first | notice_first | split_bind | freeze_both | public_bridge | sponsor_hush | runner_bridge | default
  acknowledgement_surface_or_absence: signed_stub | checksum | docket_stamp | public_line | witness_receipt | route_asset_tag | explicit_absence
  reader_to_bind: <reader id>
  recipient_to_bind: <recipient id>
  reader_left_unbound_or_absence: <reader or explicit_absence>
  recipient_left_unbound_or_absence: <recipient or explicit_absence>
  accepted_cost_or_absence: <cost or explicit_absence>

Generic notify all, approve correction, legalize, publish, settle, or redact choices cannot satisfy this rite unless the above fields are recorded.

Branches

Recall first

The player binds the stale holder before the affected party response is complete.

Expected result:

• stale_dispatch_risk or false_execution improves;
• affected party hostility, notice debt, public distrust, or future reader surcharge rises;
• future reader requires late rebuttal, lawful annex, public counterline, or recovery scar.

Notice first

The player gives the affected party or proxy a response boundary before stopping the stale instruction.

Expected result:

• notice_legitimacy, contradiction legibility, or public receipt improves;
• stale execution risk, schedule pressure, route asset pressure, or holder hostility rises;
• future reader accepts with rebuttal while the stale recipient still requires recall acknowledgement.

Split bind

The player binds different readers and recipients with different surfaces.

Expected result:

• at least one route remains playable because scope is legible;
• handler burden, proof burden, source ambiguity, or public confusion rises;
• future route uses a split reader table instead of universal acceptance.

Freeze both

The player uses lawful or archive authority to suspend both the stale instruction and the row’s future-reader use.

Expected result:

• false execution and false authority risk fall;
• inspection heat, bureau debt, schedule pressure, sponsor pressure, or route delay rises;
• future route is blocked until arbitration, annex, or dual acknowledgement exists.

Public bridge

The player publishes a public counterline that simultaneously marks the stale instruction unsafe and gives the affected party a visible answer.

Expected result:

• public legitimacy, reader scope, or anti-capture improves;
• witness exposure, sponsor pressure, public confusion, or contradiction pressure rises;
• lawful reader still requires annex or bridge; public reader may accept with cost.

Sponsor hush

The player uses sponsor or manager pressure to quiet both surfaces without resolving the authority conflict.

Expected result:

• immediate slot, sponsor, or schedule pressure falls;
• contract capture, false notice, public distrust, or future sponsor unwind rises;
• default is armed unless a later public/lawful/route acknowledgement is paid.

Runner bridge

The player assigns a low-rank or exposed carrier, such as 交接链跑腿 Storyline or Redaction Stenographer, to carry synchronized recall and rebuttal surfaces.

Expected result:

• recipient and reader acknowledgement can both improve;
• runner risk, payroll leak, stenographer exposure, custody noise, or favor debt rises;
• a route asset accepts only if the carried tag, checksum, or receipt is preserved.

Default / no arbitration

The player cannot assign credible authority, hides one side, treats recall as rebuttal, treats rebuttal as recall, or leaves acknowledgement blank.

Expected result:

• 召回反驳错绑定 fires or is armed;
• future route becomes blocked, captured, split without acknowledgement, hostile, sponsor-only, lawful-only, or recovery-only;
• at least three counters or durable states change.

Resolution contract

Every resolved branch must record:

resolution:
  selected_binding_order: <branch>
  acknowledgement_surface: <surface or explicit_absence>
  bound_recipients: []
  bound_readers: []
  unbound_or_explicit_absence: []
  relief_deltas: []
  cost_deltas: []
  future_route_effect: <effect>
  recovery_scar_if_any: <scar or explicit_absence>

Non-goals

• Not a universal correction button.
• Not a replacement for 过期派发召回.
• Not a replacement for 读者反驳通知听证.
• Not valid if recall and rebuttal always resolve in the same order.
• Not valid if future readers and stale recipients all update without acknowledgement.
• Not triggered by fixed turn, fixed day/week, raw count, dashboard state, or lens health.