ogs.verification¶
Engine¶
Run verification checks against a PatternIR.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
pattern
|
PatternIR
|
The pattern to verify. |
required |
checks
|
list[Callable[[PatternIR], list[Finding]]] | None
|
Optional subset of OGS domain checks to run. Defaults to
|
None
|
include_gds_checks
|
bool
|
Run GDS generic checks (G-001..G-006) via
|
True
|
Returns:
| Type | Description |
|---|---|
VerificationReport
|
A VerificationReport with all findings. |
Source code in packages/gds-games/ogs/verification/engine.py
Findings¶
Bases: VerificationReport
OGS-compatible verification report with pattern_name alias.
Source code in packages/gds-games/ogs/verification/findings.py
pattern_name
property
¶
Alias for system_name — OGS calls it 'pattern_name'.
Type Checks¶
Type consistency checks T-001 through T-006.
These checks verify that individual flows and game signatures are internally consistent — that flow labels match game port types, that games have complete signatures, and that flow directions match their semantic types.
All comparisons use token-based matching (see tokens.py): signature
strings are split on + and , into normalized tokens, and
compatibility is checked via set containment (subset) or overlap.
Key distinction from structural checks (S-series): type checks validate per-flow / per-game properties, while structural checks validate global composition invariants (acyclicity, independence, etc.).
check_t001_domain_codomain_matching(pattern)
¶
T-001: For every covariant game-to-game flow, verify the flow label is consistent with source codomain (Y) or target domain (X).
Uses token-based comparison: flow label tokens must be a subset of the source Y tokens OR the target X tokens.
Source code in packages/gds-games/ogs/verification/type_checks.py
check_t002_signature_completeness(pattern)
¶
T-002: Every OpenGameIR must have all four (X,Y,R,S) slots.
Slots must be defined (even if empty set).
A game is valid if it has at least one non-empty input slot (X or R) and at least one non-empty output slot (Y or S). Games that only produce contravariant output (utility computations) have empty Y but non-empty S, which is valid.
Source code in packages/gds-games/ogs/verification/type_checks.py
check_t003_flow_type_consistency(pattern)
¶
T-003: Covariant flows must not be utility/coutility; contravariant must be.
Source code in packages/gds-games/ogs/verification/type_checks.py
check_t004_input_type_resolution(pattern)
¶
T-004: Every InputIR.schema_hint must resolve to a known type.
Source code in packages/gds-games/ogs/verification/type_checks.py
check_t005_unused_inputs(pattern)
¶
T-005: Flag inputs with no outgoing flows.
Source code in packages/gds-games/ogs/verification/type_checks.py
check_t006_dangling_flows(pattern)
¶
T-006: Flag flows whose source or target is not in the pattern.
Source code in packages/gds-games/ogs/verification/type_checks.py
Structural Checks¶
Structural composition checks S-001 through S-007.
These checks verify that the composition structure of a pattern is
well-formed — that games are wired correctly, flows respect their
direction, and the overall graph has valid topology. They operate
on the flat IR representation (PatternIR) after compilation.
Unlike type checks (T-series), which verify individual flow labels against game signatures, structural checks verify global properties like acyclicity (S-004) and composition-specific invariants.
check_s001_sequential_type_compatibility(pattern)
¶
S-001: In sequential composition G1;G2, verify Y1 = X2.
For each covariant game-to-game flow, the flow label tokens must be a subset of BOTH the source Y and target X tokens. This verifies the structural composition requirement.
Source code in packages/gds-games/ogs/verification/structural_checks.py
check_s002_parallel_independence(pattern)
¶
S-002: Games in parallel composition should share no direct flows.
Source code in packages/gds-games/ogs/verification/structural_checks.py
check_s003_feedback_type_compatibility(pattern)
¶
S-003: In feedback composition, verify the feedback flow label is consistent with the source's S (coutility) slot.
For each feedback flow, the flow label tokens must be a subset of the source S tokens.
Source code in packages/gds-games/ogs/verification/structural_checks.py
check_s004_covariant_acyclicity(pattern)
¶
S-004: Covariant flow graph must be a DAG (no cycles).
Within a single timestep, covariant data must flow in one direction — cycles would create infinite loops. Corecursive flows (Y→X across timesteps) and feedback flows (S→R, contravariant) are excluded from this check since they represent legitimate temporal or backward links.
Source code in packages/gds-games/ogs/verification/structural_checks.py
check_s005_decision_space_validation(pattern)
¶
S-005: Every decision game must have a non-empty Y (decision output) and at least one incoming contravariant flow (utility feedback).
Source code in packages/gds-games/ogs/verification/structural_checks.py
check_s006_corecursive_wiring(pattern)
¶
S-006: Validate corecursive (temporal Y→X) flow wiring.
Corecursive flows must satisfy two invariants: 1. Direction must be covariant (they carry forward data across timesteps, not backward utility). 2. The flow label tokens must be a subset of the source game's Y tokens (the data being forwarded must actually exist in the source's output).
Only runs when corecursive flows are present in the pattern.
Source code in packages/gds-games/ogs/verification/structural_checks.py
check_s007_initialization_completeness(pattern)
¶
S-007: Every initialization input must have at least one outgoing flow.