The answer is "it depends what you call an information set", and the
distinction is the result. 44,938 decision points, random play, 2/3/4/6
seats.
Reading A — information set = the seat's current projection, which is what
project(Viewer::Player(seat)) returns and what the page renders: 22
violations. Reading B — information set = the seat's observation history,
every view seen and action taken in order: 0.
The Reading A witness is concrete. Two histories reach a byte-identical
view — round 3, Select step, same hand, same claimed Problem — where the
seat had played SOLVE then GROUND-OU(protect) in one and SUPPORT then
SOLVE in the other. The view does not tell the seat what it did, because
our state is a snapshot rather than a history: selections clear each round
and effects coincide, so a player cannot reconstruct their own past from
the present. In a real game the player's memory supplies it; in the state,
nothing does.
That is precisely OpenSpiel's ObservationString vs InformationStateString
split, arrived at here by measurement rather than read off. project() is
an observation, not an information state.
So Track B is not closed, it is constrained, and usefully: an
extensive-form game built from this engine must key information sets on
observation histories, never on project().
Both directions are asserted — Reading B empty AND Reading A non-empty —
because if the sample stops finding Reading A violations the conclusion is
unsupported and must be re-derived rather than quietly kept. And the check
samples, so it can falsify perfect recall and cannot establish it: Reading
B's zero means no counterexample was drawn, which is printed as such.
Wired into make panels, so it is re-derived by the gate rather than by
hand.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0041 answers what is true of the engine as a game-theoretic object before
anything is built on it. CB-RES-0009 found the EFG is the interchange
format between describing a game and analysing it, and that we already
have most of one — the journal is the history, Outcome the payoff, and
project(Viewer::Player(seat)) the information partition. Three gaps
remain, and perfect recall is first because CFR and exploitability both
assume it and nobody has checked ours. The workplan deliberately builds no
port: creating a capability port is a tier-L trigger and this is M, so
T04 decides whether to build one and declares it separately. T01's control
includes that the answer may be NO, which would make Track B's adoption
unsound as it stands.
0042 implements H2, which is ground-game's direct answer to our H1
reading. Unclaimed Problems now tick only the seats in scope — global,
personal (the owner), or bond (the owner's Bond network over Bond edges
only, degree 0 falling back to personal) — assigned by hidden priority, so
2p never has the bond card in play. It explicitly does not stack with H1.
H2 is bigger than H1 was: it needs variant-scoped edition data (H2
overrides Problems.csv with a stress_scope column, and ours is an
include_str! constant), per-Problem ownership which is new state reaching
the hash and every recording, and Bond-network reachability. The controls
name the likely defects in advance: traversing Rivalry edges, applying
stacking once, forgetting the degree-0 fallback, and ownership silently
becoming a permission to SOLVE.
Chaos window 4 opens: d8 = 5 and d8 = 4, no overrides. Window 3's verdict
is still owed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
