Rebuttal Recall Collision / 反驳召回撞锁机制

Rebuttal Recall Collision governs the case where two correction systems touch the same authority row but do not mean the same thing.

• 过期派发召回机制 stops or records an old instruction still moving through the building.
• 读者反驳通知机制 makes a future reader’s citation answerable by an affected party.

This mechanism begins only when both pressures are live against a shared authority row, proof object, boundary, dispatch, receipt, or route asset. It answers: which correction binds which actor first, and what happens to the actor left unbound?

State model

rebuttal_recall_collision_state:
  inactive: no shared authority conflict exists
  collision_open: both stale dispatch and rebuttal notice can affect the same authority row
  arbitration_assigned: player selected binding order, carrier, acknowledgement, and cost
  recall_first_bound: stale recipient is bound before affected-party answer is complete
  notice_first_bound: future reader or affected party is bound before stale recipient is stopped
  split_bound: different readers and recipients are deliberately bound to different correction surfaces
  frozen: both stale execution and future-reader acceptance are suspended
  public_bridge: public counterline marks stale instruction unsafe and answerable, with lawful cost pending
  sponsor_hush: immediate pressure is quieted without real authority settlement
  runner_bridge: carrier attempts to bind reader and recipient with paired receipt or tag
  misbound: one correction is falsely treated as the other
  recovered_with_scar: late repair exists but future route keeps visible surcharge or restriction

Entry contract

The mechanism may open when all are true:

entry_state:
  trigger_kind: state_pressure
  shared_authority_row_present: true
  stale_instruction_still_actionable: true
  future_reader_wants_to_consume_authority: true
  affected_party_or_explicit_absence_present: true
  stale_holder_or_explicit_absence_present: true
  recall_boundary_unresolved_or_partial: true
  rebuttal_boundary_unresolved_or_partial: true
  future_route_can_change_by_binding_order: true
  player_can_assign_arbitration_or_default: true
  no_fixed_turn_trigger: true
  no_fixed_day_or_week_trigger: true
  no_raw_count_trigger: true
  no_dashboard_or_lens_health_trigger: true

The shared authority can be a transcript row, rehearsal trace, dispatch line, custody copy, sponsor copy, public receipt, ward order, fan queue receipt, pirate packet, archive docket, or route asset tag.

Binding rules

Rule 1 — Recall is not rebuttal

A recall proves that a stale recipient was told to stop, narrow, patch, retract, quarantine, or acknowledge an instruction. It does not prove that the affected party answered the cited authority row.

Rule 2 — Rebuttal is not recall

A rebuttal proves that the affected party, proxy, or explicit absence had an answer boundary. It does not prove that floor, cutroom, sponsor, ward, runner, archive, inspector, fan delegate, or route asset holder stopped executing an old instruction.

Rule 3 — Binding order matters

The same two corrections produce different future route states depending on order:

• recall first protects local execution but can create no-notice debt;
• notice first protects answerability but can leave stale execution risk;
• split bind preserves scope but increases proof burden;
• freeze both prevents false action but blocks route progress;
• public bridge creates legitimacy and public confusion together;
• sponsor hush buys slot relief and hardens contract capture;
• runner bridge creates paired acknowledgement and carrier risk.

Rule 4 — Acknowledgement is per actor

A valid resolution records which readers and recipients are bound. Notify all is not a state. Missing acknowledgement is allowed only if explicit absence is itself the branch cost.

Rule 5 — Misbinding is durable

When recall is filed as rebuttal, rebuttal is filed as recall, or split binding lacks a table, 召回反驳错绑定 must change future play.

Resolution branches

Branch	Relief	Cost	Future effect
recall_first_bound	stale execution risk falls	no-notice debt or affected-party hostility rises	late rebuttal / annex / counterline required
notice_first_bound	answerability and public/lawful legitimacy improve	stale execution risk or schedule pressure rises	recall stamp or checksum still required
split_bound	scoped route remains playable	proof burden, handler burden, source ambiguity rise	split reader table required
frozen	false execution and false authority risk fall	inspection heat, schedule delay, sponsor pressure rise	route blocked until arbitration or dual ack
public_bridge	public legitimacy and anti-capture improve	sponsor heat, witness exposure, contradiction pressure rise	public reader may accept; lawful reader needs bridge
sponsor_hush	immediate sponsor or slot pressure falls	contract capture and false notice risk rise	sponsor unwind or public/lawful repair required
runner_bridge	paired recipient/reader acknowledgement possible	runner risk, payroll leak, custody noise, stenographer exposure rise	route asset accepts only with carried tag or checksum
misbound	short-term burden may fall	false authority, stale execution, hostility, public confusion rise	blocked, hostile, sponsor-only, lawful-only, or recovery-only

Counter contract

Every branch resolution must mutate at least three counters or durable states:

• one relief;
• one cost;
• one future-reader, stale-recipient, route-asset, route-access, or recovery effect.

Recommended counters and states:

• correction_authority_conflict
• stale_dispatch_risk
• notice_legitimacy
• false_authority
• false_execution
• future_reader_acceptance
• affected_party_hostility
• proof_burden
• handler_burden
• schedule_pressure
• public_confusion
• sponsor_stop_loss_pressure
• contract_capture
• inspection_heat
• edit_debt
• runner_risk
• route_asset_pressure
• recovery_scar

Recovery model

Recovery may reopen the collision only if the scar remains:

• late rebuttal;
• late recall stamp;
• dual acknowledgement;
• split reader table;
• lawful-only route;
• public-only route;
• sponsor unwind;
• route asset narrowed;
• substitute proof;
• recovery-only access.

Non-goals

• Not a third generic notice system.
• Not an automatic merger of Stale Dispatch Recall and Reader Rebuttal Notice.
• Not a dashboard or governance mechanism.
• Not a raw scale target.
• Not valid if old instructions and future readers synchronize for free.
• Not valid if no actor is left bound or unbound by the selected correction order.