Recognized Broadcast Basis / 播出确认基准线

Recognized Broadcast Basis is the storyline for a result that happened but has not yet been accepted under one shared basis.

The broadcast aired, the correction ran, the custody proof survived, the sponsor received a deliverable, the public saw a receipt, or the route asset escaped. The result is real. The pressure begins when different factions count different versions as the official basis for payment, certification, public memory, route access, or future proof.

Primary playable question

When success is countable in more than one way, who gets to define what the success means — and what future route becomes harder because that basis excludes someone?

This storyline keeps the original result true. It does not retcon play. It makes recognition into a scarce and faction-owned state.

Gap diagnosis

The current mesh is already strong in adjacent areas:

• 播出合约回读线 makes contract wording playable.
• 播出盈余认领线 makes positive surplus contestable.
• 播出破产账本线 makes unpaid promises dangerous.
• 播出合法性转轨线 makes lawful/public channel mismatch playable.
• 导出证据回流分岔线 makes replay-derived proof return as in-world pressure.
• Route Assets and Custody already requires durable state for people, proofs, copies, and routes.

The remaining gap is recognition basis. A branch can currently succeed, produce surplus, create debt, or return proof, but the game still needs a shared pressure surface for which version is counted before later systems spend, certify, invoice, publish, or route-gate that result.

State-triggered entry

Open this storyline only when all are true:

entry_required:
  trigger_kind: state_pressure
  source_result_exists: true
  source_result_kept_true: true
  source_result_countable_by_multiple_channels: true
  recognition_claimants_min: 2
  excluded_reader_or_route_asset_present: true
  future_route_or_counter_can_change: true
  no_fixed_turn_trigger: true

Never open it from fixed turn count, day interval, chapter marker, lens health, raw content count, or generic post-victory pacing.

Content pack

Mechanic

• 播出确认基准机制 defines recognition channels, state machine, branch outcomes, counters, and replay evidence.

Card

• 确认基准账本 stores the source result, basis rows, proof anchor or absence, excluded reader, demanded recognition, and default if unanswered.

Rite

• 基准确认听证 resolves recognition through single-basis recognition, split basis, escrow, re-audit, refusal, or default booking.

Event

• 误认基准违约 fires or is armed when a wrong/private/first claimant basis is booked without a visible row, proof, excluded reader, and future effect.

Storyline sequence

Beat 1 — A result becomes countable

A prior branch creates a real result: broadcast delivery, legality conversion, route rescue, public correction, sponsor settlement, memorial proof, edit checksum, fan oxygen receipt, or replay-derived evidence.

The result remains true; no branch here can erase it.

Beat 2 — Basis rows appear

确认基准账本 records at least two rows:

• sponsor wants contract delivery counted;
• archive or inspector wants lawful certification counted;
• fan/public wants receipt or oxygen queue proof counted;
• editor wants checksum or final cut counted;
• artist, handler, witness, or route asset wants survival, refusal, recovery, or safe custody counted;
• producer wants reserve or delay counted.

Each row must name what it excludes.

Beat 3 — The player chooses a basis response

基准确认听证 is offered or explicitly blocked by missing proof, missing handler, missing support, or missing excluded reader.

Valid responses:

• recognize one basis with scar;
• split basis across channels;
• escrow recognition;
• force a re-audit;
• refuse recognition;
• let a claimant book by default.

Beat 4 — Future acceptance changes

At least one future route, proof use, payable claim, certification, correction right, custody gate, or public route changes.

A branch is not valid if it only changes sentiment or score.

Beat 5 — Misrecognized basis becomes pressure

If the producer hides the ledger, accepts clean recognition, underfills the rite, uses replay proof as a debug object instead of in-world proof, or lets a faction count first, 误认基准违约 mutates future state.

Branch matrix

Branch	Immediate relief	Required scar	Future effect
Recognize single basis	One channel can use the result.	Rival or excluded reader gains pressure.	Later rites must check recognized channel.
Split basis	Multiple channels get weaker recognition.	Source ambiguity or claimant collision rises.	Future use must declare channel.
Escrow basis	Bad booking is delayed.	Reserve, schedule, or resentment rises.	Default can fire if a proof or claimant moves first.
Force re-audit	Weak or false basis pressure decreases.	Inspection, exposure, burden, or schedule cost rises.	Re-audit result must be consumed later.
Refuse recognition	False clean count is blocked.	Sponsor, public, lawful, or route pressure rises.	Route becomes disputed, public-only, lawful-only, or recovery-only.
Let default book	A claimant counts first.	Default event records wrong/private/first basis.	Future route, payment, proof, or custody gate changes.

Counters and states

The storyline expects at least three surfaces to mutate on resolution:

• basis_state
• recognized_channel
• basis_split
• basis_escrow
• basis_reaudit_open
• excluded_reader_hostility
• budget_pressure
• sponsor_stop_loss_pressure
• contract_capture
• lawful_buffer
• inspection_heat
• archive_debt
• public_receipt_legitimacy
• public_receipt_distrust
• fan_oxygen_resentment
• edit_lane_credit
• edit_debt
• source_ambiguity
• handler_burden
• route_asset_pressure
• future_route_acceptance
• recovery_route_cost

Missability and recovery

This storyline is missed when a result is marked clean without basis rows, when a sponsor/archival/public result is counted silently, when replay proof is accepted without in-world object, or when all factions receive full benefit from one basis.

Recovery is allowed only with named scar:

• reopen the hearing with the excluded reader present;
• split the basis and accept ambiguity;
• convert the wrong basis into an insolvency row;
• move the claimant into claimant conversion;
• accept recovery-only use for the affected route asset;
• force a re-audit that raises heat or burden.

Replay/session evidence shape

storyline_id: storyteller.storyline.recognized_broadcast_basis.v1
session_id: lens-storyteller-recognized-broadcast-basis-v1-<timestamp>
seed: <deterministic-seed>
source_result:
  source_surface: <storyline rite event card replay source or in-world proof>
  source_session_id: <session or explicit_absence>
  source_result_kept_true: <result>
entry_state:
  trigger_kind: state_pressure
  basis_rows_min: 2
  recognition_claimants:
    - <claimant>
    - <claimant>
  proof_anchor_or_absence_visible: true
  excluded_reader_or_route_asset_present: true
  future_effect_if_unanswered_present: true
  no_fixed_turn_trigger: true
offered:
  card: storyteller.card.recognized_basis_ledger.v1
  rite: storyteller.rite.basis_recognition_hearing.v1
branch_result:
  selected_response: recognize_single_basis | split_basis | escrow_basis | force_reaudit | refuse_recognition | let_default_book
  assigned_inputs:
    basis_row: <basis id>
    proof_anchor_or_absence: <proof or explicit_absence>
    handler_or_absence: <handler or explicit_absence>
    support_or_absence: <support or explicit_absence>
  basis_state_after: recognized_single | split_basis | escrowed_basis | reaudit_open | misrecognized | recovery_only_basis
  recognized_channel: <channel or none>
  excluded_reader_effect: <effect>
  future_route_effect: <effect>
  emitted_event: storyteller.event.misrecognized_basis_default.v1 | none
  counter_deltas:
    relief:
      - <relief>
    cost:
      - <cost>

Non-goals

• Not filler content.
• Not a passive accounting dashboard.
• Not a governance/process page.
• Not raw lens-count satisfaction.
• Not a fixed-turn trigger.
• Not a clean ending repair.
• Not valid unless the source result remains true while recognition changes future playable state.