Skip to content

FAQ.md

Latest commit

 

History

History
1535 lines (902 loc) · 36.3 KB

FAQ.md

File metadata and controls

1535 lines (902 loc) · 36.3 KB
Raw

❓ FAQ — SSG

Structural Stability Geometry

Balance Is a Closed Return Relation

admissible disturbance -> return OR redistribution OR arrest

SECTION A — Core Understanding

A1. What is SSG?

SSG, or Structural Stability Geometry, is a research framework for studying stability through admissible transitions and closed return structure.

Its central principle is:

Physical balance is not merely the location of the centre of mass. Physical balance exists when every admissible disturbance encounters a structural route that returns, redistributes, or arrests it before an escape mode opens. Balance is not a point. Balance is a closed return relation.

The current repository provides a deterministic finite-graph realization of this principle.

Four native solvers compute the same canonical parity-game subject. Four assurance layers then observe agreement, verify transition truth, diagnose disagreement, and govern release certification.

A2. What is the core idea in one line?

stability = every admissible disturbance remains enclosed by return, redistribution, or arrest before escape becomes recurrent

A3. How is SSG different from a centre-of-mass calculation?

A centre-of-mass calculation describes an important geometric property of a system.

SSG asks a different question:

What happens after an admissible disturbance enters the system?

A system may begin in a balanced configuration and still contain an admissible route to escape, divergence, collapse, or unrecoverable motion.

SSG therefore studies:

balanced state + admissible disturbance + admissible transitions + recurrent outcome

The centre of mass helps describe the starting condition.

The closed return relation describes whether stability survives disturbance.

A4. What do return, redistribution, arrest, and escape mean?

Return means the disturbance contracts toward an admitted stable region.

Redistribution means the disturbance is transferred through another valid structural route without opening an escape mode.

Arrest means a guard, barrier, policy, or constraint prevents further destabilizing motion.

Escape means an admissible path leaves the certified return structure or permits an adverse recurrent mode.

Compact relation:

admissible disturbance -> return OR redistribution OR arrest

unresolved admissible path -> escape

A5. What is a closed return relation?

A closed return relation is a set of states and transitions that remains self-contained under every admitted move.

For a declared winning region:

selected owner transitions remain inside the region

and:

all opponent transitions remain inside the region

and:

no reachable recurrent cycle has an adverse maximum priority

Closure must survive both the selected strategy and every admitted opposing move.

A6. Is SSG only a mathematical idea?

No.

SSG is a broader structural-stability research direction.

The repository demonstrates one exact digital and formal realization using finite games, deterministic solvers, transition certificates, disagreement diagnostics, and governance evidence.

The current repository should be evaluated for what it directly contains:

  • finite graph computation
  • parity-game solving
  • strategy certification
  • recurrent-cycle analysis
  • deterministic replay
  • evidence integrity
  • controlled fault diagnosis
  • release governance

Physical-domain validation requires additional empirical evidence.

A7. What is the current system release?

The current consolidated system is:

SSG Native Solver System v1.0.0

It contains:

  • 4 native solvers
  • 4 assurance layers
  • 8/8 complete component executions
  • 238/238 source-manifest files
  • 11/11 system source-verification gates
  • 12/12 system certification gates
  • final state RELEASE_CERTIFIED

A8. What is SSG-DCL?

SSG-DCL means:

Structural Stability Geometry Digital Conformance Laboratory

It is the deterministic laptop-based branch used to express and test closed-return semantics without requiring an external dataset, physical laboratory, network service, or additional hardware.

The native solver system uses the canonical finite-game subject developed through that branch.

SECTION B — Why a Parity Game?

B1. What is a parity game?

A parity game is a finite directed graph.

Every vertex has:

  • an owner
  • one or more successors
  • a non-negative priority

A play follows graph edges indefinitely.

The winner is determined by the parity of the highest priority that occurs infinitely often.

Core condition:

winner = parity(maximum priority recurring infinitely often)

B2. Why is a parity game relevant to structural stability?

Parity games combine four properties that are useful for SSG:

  • adversarial choice
  • infinite execution
  • recurrent behavior
  • exact positional certificates

They allow the system to ask:

Can one participant preserve a closed winning region against every admitted opposing transition?

This corresponds structurally to preserving return closure under disturbance.

B3. What do the two participants represent?

The repository uses the labels:

  • controller
  • environment

The controller represents the participant attempting to preserve the declared controller-winning condition.

The environment represents the opposing participant.

These labels are formal roles in the finite game.

They do not automatically represent a physical controller, natural environment, person, machine, or institution.

B4. What is a winning region?

A winning region is the set of vertices from which one participant has a strategy that guarantees the required parity outcome against every legal opposing choice.

The canonical graph is completely partitioned:

controller-winning vertices = 2720

environment-winning vertices = 3041

2720 + 3041 = 5761

No canonical vertex remains unclassified.

B5. What is a positional strategy?

A positional strategy selects one successor at every winning vertex owned by the declared winner.

The selected move depends only on the current vertex.

It does not require the complete play history.

Each bundled solver produces:

strategy entries = 2913

The four solvers preserve the same winner partition but produce four distinct strategy identities.

B6. How can different strategies certify the same winners?

A winning vertex may have more than one legal winning successor.

Two solvers may select different valid successors while preserving:

  • the same winning region
  • the same region closure
  • the same recurrent parity
  • the same final winner

Therefore:

winner equality required

strategy equality not required

Strategy diversity is useful evidence that agreement is not limited to copying one identical move selection.

B7. What is an adverse recurrent cycle?

An adverse recurrent cycle is a reachable cycle whose maximum recurring priority has the wrong parity for the declared winner.

Such a cycle would allow an infinite play that contradicts the winner certificate.

STRAL searches exact opposite-parity obligations and reports:

adverse recurrent cycles = 0

B8. Is the canonical game the only possible SSG subject?

No.

It is the frozen subject supplied with this release.

The current system can be extended to additional finite parity games, wider priority ranges, larger graph families, and independently generated challenge cases.

Every broader claim must be supported by corresponding evidence.

SECTION C — Canonical Subject

C1. What is the size of the canonical graph?

The bundled canonical graph contains:

  • 5,761 vertices
  • 15,105 directed edges
  • 3 priorities
  • 2,720 controller-winning vertices
  • 3,041 environment-winning vertices

C2. What are the frozen subject identities?

Canonical game file identity:

5b7fb23509ffcb2a6a9e2245a5fce26fc43ff72bba11a78b38d294e7088588a1

Graph subject identity:

c74b119c64eb782e4a00f118b98b1a271c20cc4a0a22ddf72818384055abca7d

Winning-partition identity:

dae558afa2b17a5bed8b304b426f8bbb50dcf9c0d560bcb4db0db3b2f4e9faf0

These values allow reviewers to confirm that they are examining the same frozen structures.

C3. Does a matching hash prove correctness?

No.

A matching hash proves file or structural identity relative to the referenced digest.

It does not independently prove:

  • mathematical correctness
  • authorship
  • security
  • absence of defects
  • physical validity
  • external trustworthiness

Correct interpretation:

matching hash = matching identity

matching hash != complete correctness proof

Behavioral and mathematical claims require the corresponding verification campaigns.

C4. Why is the graph subject identity different from the game-file identity?

The game-file identity binds the exact serialized file.

The graph subject identity binds the canonical structural content.

A representation may change without changing structural meaning.

This distinction supports metamorphic checks such as row-order or formatting changes.

SECTION D — Native Solver Family

D1. Why are there four native solvers?

A single solver can contain an unnoticed defect.

The repository therefore uses four structurally different solution routes.

The goal is not to count repeated executions of one algorithm.

The goal is to compare distinct computational structures that must converge on the same winner partition.

The four solvers are:

  1. STOCRS-PG
  2. SRA-PG
  3. SSG-SSIL-CRS
  4. SBM-SSAU-SACS

D2. Are the four solvers independent third-party implementations?

No.

They are separate native implementations with distinct algorithmic structures inside the same repository family.

They were not all authored, hosted, or certified by unrelated external organizations.

The accurate claim is:

Four structurally distinct native solver architectures produce the same frozen winner partition and independently checkable strategies.

D3. What does STOCRS-PG do?

STOCRS-PG resolves winner claims through dependency closure.

Core chain:

claim -> dependencies -> closure -> resolved winner

Selected validated metrics:

  • 16 dependency closures
  • 10,824 dependency-claim resolutions
  • 17 recursive calls
  • maximum depth 5
  • 30 valid strategy choices different from the reference
  • 12/12 controlled mutations rejected

Folder:

../SSG_NATIVE_SOLVER_SYSTEM_v1_0_0/COMPONENTS/STOCRS_PG/

D4. What does SRA-PG do?

SRA-PG resolves the game through an exact nested fixed-point lattice.

Fixed-point form:

nu Y2 . mu Y1 . nu Y0 . F(Y0,Y1,Y2)

Selected validated metrics:

  • 530,012 admissibility evaluations
  • fixed-point rounds 3 / 12 / 92
  • 587 valid strategy choices different from the reference
  • 14/14 controlled mutations rejected

Folder:

../SSG_NATIVE_SOLVER_SYSTEM_v1_0_0/COMPONENTS/SRA_PG/

D5. What does SSG-SSIL-CRS do?

SSG-SSIL-CRS uses a closed-return pressure measure.

Core interpretation:

finite pressure -> closed return remains resolvable

TOP -> adverse escape pressure is unresolved

Selected validated metrics:

  • pressure bound 433
  • top value 434
  • 1,681,603 lift evaluations
  • 1,029,310 measure raises
  • odd-return kernel size 2,369
  • 2,069 valid strategy choices different from the reference
  • 16/16 controlled mutations rejected

Folder:

../SSG_NATIVE_SOLVER_SYSTEM_v1_0_0/COMPONENTS/SSG_SSIL_CRS/

D6. What does SBM-SSAU-SACS do?

SBM-SSAU-SACS derives an exact structural alphabet, refines equivalent classes, solves a quotient graph, and lifts the result back to the full arena.

Core chain:

arena -> structural alphabet -> exact quotient -> quotient solution -> lifted solution

Selected validated metrics:

  • 5,761 vertices compressed to 703 exact blocks
  • 15,105 edges compressed to 2,493 quotient edges
  • 8 refinement rounds
  • largest block size 193
  • 240 singleton blocks
  • 463 nontrivial blocks
  • 120 valid strategy choices different from the reference
  • 18/18 controlled mutations rejected

Folder:

../SSG_NATIVE_SOLVER_SYSTEM_v1_0_0/COMPONENTS/SBM_SSAU_SACS/

D7. Which solver is considered the final authority?

No single native solver is treated as the sole family authority.

Each solver produces its own evidence and certificate.

The family layer requires:

  • complete winner-partition agreement
  • valid strategy evidence from every solver
  • exact certificate identity checks
  • transition verification
  • zero unresolved disagreement

D8. Are the solvers ranked?

No.

The system does not rank the native solvers by importance, elegance, speed, or authority.

Native work fields are observed without turning them into a cross-solver score.

SECTION E — Assurance Layers

E1. Why are assurance layers separate from the solvers?

Winner computation and evidence assurance are different responsibilities.

The separation is:

solvers determine

SSC-Core observes

STRAL verifies

SSD diagnoses

SAIL governs

An assurance layer must not silently change the winner computed by a solver.

E2. What does SSC-Core do?

SSC-Core is the Solver-Family Observatory.

It verifies:

  • four admitted solver evidence packs
  • six pairwise agreement edges
  • one shared winning partition
  • four distinct strategy identities
  • native work-field preservation
  • deterministic family certificates

Core result:

pairwise agreement edges = 6 / 6

winner-partition identities = 1

strategy identities = 4

SSC-Core does not rerun or rank the solvers.

E3. What does STRAL do?

STRAL is the unified transition-truth checker.

It verifies:

  • exact strategy domains
  • legal selected edges
  • winning-region preservation
  • closure under all opposing transitions
  • recurrent strongly connected components
  • opposite-parity obligations
  • absence of adverse recurrent cycles

Validated totals:

selected strategy transitions = 11652

opponent-controlled transitions = 24832

opposite-priority obligations = 12

adverse recurrent cycles = 0

E4. What does SSD do?

SSD is the Solver Disagreement Diagnostic.

It classifies:

  • input identity failure
  • winner divergence
  • strategy-domain erosion
  • illegal transition
  • region-closure breach
  • adverse recurrent cycle
  • certificate-chain corruption
  • observatory-evidence mismatch

For every controlled fault, SSD produces:

first divergence -> cause -> propagation path -> severity -> recovery or quarantine action

Validated result:

  • baseline diagnoses 0
  • diagnostic classes 8/8
  • controlled cases diagnosed 16/16
  • first divergences localized 16/16

E5. What does SAIL do in this system?

SAIL governs the admitted evidence chain.

It certifies:

  • requirements
  • requirement realization
  • solver admission
  • federation quorum
  • partition consensus
  • compliance controls
  • incident clearance
  • release eligibility

It does not solve the parity game.

Release rule:

release certified iff all requirements certified AND four solvers admitted AND family consensus certified AND transition truth certified AND baseline health confirmed AND all compliance controls pass AND no incident remains unresolved

E6. Can an assurance layer influence the winner?

No.

The documented architecture and component evidence enforce the following separation:

  • SSC-Core is not used in winner computation.
  • STRAL is not used in winner computation.
  • SSD is not used in winner computation.
  • SAIL is not used in winner computation.

A violation of this separation would break a core system boundary.

E7. What does RELEASE_CERTIFIED mean?

It is an internal governance state.

It means that the bundled requirements, solver admissions, evidence identities, family consensus, transition truth, diagnostic health, compliance controls, and incident conditions satisfy the implemented release policy.

It does not mean accreditation by a regulator, standards body, government, laboratory, university, engineering authority, or unrelated external organization.

SECTION F — Evidence, Certificates, and Replay

F1. What is a certificate in SSG?

A certificate is a deterministic structural artifact or identity produced from a defined evidence subject under implemented SSG rules.

Certificates commonly include or bind SHA-256 identities for items such as:

  • graph subjects
  • winner partitions
  • strategies
  • solver traces
  • transition truth
  • family consensus
  • diagnostic campaigns
  • governance states

A certificate records an internal computational or structural result.

It is not external accreditation, regulatory approval, or independent institutional certification.

F2. What is the primary replay invariant?

same frozen structure -> same evidence -> same certificate -> same replay result

F3. What is deterministic replay?

Deterministic replay means that the same admitted inputs and rules reproduce the same structural artifacts and certificate identities.

Replay excludes operational fields that should not change proof identity, such as:

  • timestamps
  • output-directory names
  • interface state
  • transient process identifiers

F4. Why do evidence mode and complete mode have different stable certificates?

Execution mode is part of the system record.

Evidence mode certifies reconstruction of the frozen evidence chain.

Complete mode records execution of all eight component campaigns.

Therefore:

evidence-mode record != complete-mode record

Their stable certificates differ.

Their decisive mathematical and governance identities remain the same:

  • graph subject
  • winner partition
  • component certificates
  • SAIL release certificate

F5. What are the two system stable certificates?

Evidence mode:

5cb19686ed8df286242586772463b94b214eaec01d34350da99608cdfce2e5b2

Complete mode:

bd945eccef89bc3269121a985eb3ab9e9d32d6297b9fb9f68598a8e5fa2166d9

F6. Where are the primary evidence records?

Repository-level evidence:

Component primary evidence is also retained under:

../SSG_NATIVE_SOLVER_SYSTEM_v1_0_0/EVIDENCE/PRIMARY/

F7. What is the final SAIL release certificate?

9fd2a7e39898718d5cb5f8cbd80618b90903e2a1f1f08a4b109d60872090509b

This binds the admitted governance subject.

It does not replace the native solver or transition certificates.

SECTION G — Validation and Testing

G1. How extensively has the system been tested?

The eight components contain separate source-verification and controller campaigns.

Component Source gates Campaign gates
STOCRS-PG 16/16 24/24
SRA-PG 21/21 27/27
SSG-SSIL-CRS 21/21 31/31
SBM-SSAU-SACS 21/21 33/33
SSC-Core SFO 25/25 40/40
STRAL USFCC 30/30 48/48
SSD SDD 34/34 46/46
SAIL SFGRC 31/31 57/57
Total 199/199 306/306

The consolidated system adds:

  • 11/11 source-verification gates
  • 12/12 system certification gates
  • 8/8 complete component executions
  • 238/238 manifest files verified

These are implemented verification gates.

They are not independent scientific studies or statistical sample counts.

G2. What mutation testing is included?

Controlled mutations deliberately damage evidence or source assumptions and require rejection.

The campaigns include:

  • 60/60 solver-level mutations rejected
  • 20/20 SSC-Core mutations rejected
  • 24/24 STRAL evidence mutations rejected
  • 16/16 SSD controlled disagreements diagnosed
  • 16/16 SAIL governance failures blocked

Mutation testing demonstrates sensitivity to the supplied fault operators.

It does not prove detection of every possible defect.

G3. What is metamorphic testing?

Metamorphic testing changes representation while preserving structural meaning.

The result should remain unchanged.

Examples include:

  • graph-row reversal
  • successor-order reversal
  • label removal
  • CRLF conversion
  • JSON key reordering
  • JSON whitespace changes
  • solver-registry reversal

The component family satisfies:

45/45 metamorphic relations

G4. What is an independent checker?

An independent checker is a separate implementation that reconstructs or validates a certificate subject without relying on the same code path as the primary producer.

The system uses both Python and Node.js implementations to increase implementation diversity.

This is implementation-level independence.

It is not the same as independent organizational authorship or external accreditation.

G5. Does zero disagreement prove universal correctness?

No.

It proves zero disagreement among the admitted solver results for the frozen subject after the implemented verification checks.

Broader correctness requires:

  • additional challenge graphs
  • additional solver implementations
  • broader priority ranges
  • more fault operators
  • independent review
  • continued falsification attempts

G6. Why preserve blocked and failing cases?

A reliable verifier must reject invalid structures.

Testing only successful cases would not establish fail-closed behavior.

The campaigns therefore include:

  • malformed inputs
  • missing fields
  • illegal successors
  • winner changes
  • strategy erosion
  • region escapes
  • adverse recurrent cycles
  • certificate corruption
  • evidence mismatches
  • unresolved incidents
  • release-policy failures

SECTION H — Running the System

H1. What software is required?

  • Python 3.10 or later
  • Node.js 18 or later
  • Windows or Linux command line

No third-party runtime package is required by the supplied campaigns.

H2. Is administrator access required?

No.

The system is designed to run without administrator rights.

H3. Is network access required?

No.

The supplied verification and complete campaigns run offline.

H4. Is an external solver required?

No.

All four native solvers are included.

H5. Is an external dataset required?

No.

The canonical graph and evidence subjects are included.

H6. How do I run the fast verification on Windows?

From:

SSG_NATIVE_SOLVER_SYSTEM_v1_0_0

Run:

VERIFY_SSG_NATIVE_SOLVER_SYSTEM_v1_0_0_WINDOWS.cmd

Then run:

RUN_SSG_NATIVE_SOLVER_SYSTEM_v1_0_0_WINDOWS.cmd

Expected source classification:

SSG_NATIVE_SOLVER_SYSTEM_V1_0_0_SOURCE_VERIFIED

Expected system classification:

SSG_NATIVE_SOLVER_SYSTEM_REPRODUCIBILITY_AND_CERTIFICATION_SEALED

Expected state:

RELEASE_CERTIFIED

H7. How do I run the complete campaign?

From the system directory:

python SSG_NATIVE_SOLVER_SYSTEM_v1_0_0_Controller.py --mode complete --out SSG_NATIVE_SOLVER_SYSTEM_V1_0_0_COMPLETE_OUT

Expected:

8 / 8 components pass

mode = complete

release_state = RELEASE_CERTIFIED

H8. What is the difference between evidence mode and complete mode?

Evidence mode verifies the frozen certificate chain and all admitted identities.

It is fast and suitable for an initial review.

Complete mode reruns every native solver and assurance campaign through the master controller.

It takes longer and provides end-to-end execution evidence.

H9. Does complete mode change the sealed source?

No.

It writes generated artifacts to the specified output directory.

The source manifest remains unchanged.

H10. Why can complete mode take longer?

It reruns all component campaigns.

The SRA admissibility-lattice campaign and the closed-return pressure campaign perform substantial exact computation.

Runtime depends on:

  • processor
  • storage
  • Python version
  • Node.js version
  • operating system

H11. How do I run the system on Linux?

From the system directory:

chmod +x verify_ssg_native_solver_system_v1_0_0_linux.sh
chmod +x run_ssg_native_solver_system_v1_0_0_linux.sh

Then:

./verify_ssg_native_solver_system_v1_0_0_linux.sh

and:

./run_ssg_native_solver_system_v1_0_0_linux.sh

SECTION I — Repository and Review

I1. How is the repository organized?

LICENSE
README.md

docs/
evidence/
SSG_NATIVE_SOLVER_SYSTEM_v1_0_0/
VERIFY/

The executable system contains:

COMPONENTS/
EVIDENCE/
REFERENCE/

The eight component folders are retained inside COMPONENTS/.

I2. Why are historical development folders not included?

The repository focuses on the consolidated executable baseline.

Historical intermediate folders would duplicate files and make the review path less clear.

The consolidated system contains the required solver and assurance implementations.

I3. Why are generated output directories not committed inside the system folder?

Generated output directories are execution products.

Committing them inside the sealed source tree would mix source and runtime artifacts.

The key evidence-mode and complete-mode primary results are stored separately under evidence/.

I4. Where should a reviewer begin?

Recommended order:

  1. Read ../README.md.
  2. Read SSG-Architecture.md.
  3. Read Claim-Boundary.md.
  4. Run source verification.
  5. Run evidence mode.
  6. Compare the primary evidence records.
  7. Run complete mode.
  8. Inspect component algorithms and fixtures.
  9. Attempt the falsification targets.

I5. Which files define the complete certificate registry?

SECTION J — Scope and Boundaries

J1. Does SSG prove that a real building is stable?

No.

The current repository proves finite-game properties for the bundled formal subject.

A real building requires evidence about:

  • geometry
  • materials
  • connections
  • loads
  • damping
  • friction
  • damage
  • construction quality
  • boundary conditions
  • uncertainty
  • measurement quality

The current finite-game demonstration does not replace those requirements.

J2. Does SSG replace professional engineering?

No.

SSG does not replace:

  • licensed engineering judgment
  • structural analysis
  • material testing
  • laboratory testing
  • field inspection
  • building codes
  • safety review
  • domain-specific simulation

J3. Does the repository establish physical validation?

No.

Correct distinction:

digital and formal conformance != empirical physical validation

The repository establishes a computational and assurance foundation.

Physical claims require physical evidence.

J4. Does SSG claim universal parity-game correctness?

No.

The strongest bundled conformance evidence concerns one frozen three-priority parity game.

The algorithms and checkers are inspectable and extendable, but universal claims require broader challenge families and independent analysis.

J5. Does certified mean regulatory certification?

No.

Within this repository, certified means that a visible structural subject satisfied the implemented rules and produced a deterministic certificate.

It does not mean legal, regulatory, governmental, institutional, engineering, safety, security, or standards accreditation.

J6. Is the system ready for safety-critical deployment?

No such claim is made.

Safety-critical use would require extensive domain-specific validation, threat analysis, independent assessment, operational controls, and applicable regulatory approval.

J7. Are the testing counts proof of scientific universality?

No.

The counts describe the supplied verification campaigns.

They show substantial internal qualification and deterministic replay.

They do not establish universal empirical truth.

SECTION K — Common Skeptic Questions

K1. Could all four solvers share the same hidden mistake?

Yes, a shared input assumption, schema error, or common conceptual error is possible.

The system reduces this risk through:

  • structurally distinct algorithms
  • different strategy identities
  • Python and Node.js checker diversity
  • exact transition verification
  • controlled mutations
  • metamorphic relations
  • explicit claim boundaries

It does not eliminate every possible common-mode defect.

K2. Is agreement circular because every layer uses the same evidence?

The assurance chain is intentionally layered.

Each layer asks a different question:

solver -> who wins?

SSC-Core -> do the solver evidence packs agree?

STRAL -> are the supplied strategies structurally winning?

SSD -> where does a disagreement or corruption begin?

SAIL -> is the admitted evidence chain eligible for release?

The layers share frozen subjects but do not perform the same responsibility.

K3. Why not rely only on STRAL and remove the solvers?

STRAL verifies supplied winner and strategy claims.

It does not generate the winner partition.

Without native solvers, there would be no independently produced solution claims to verify.

K4. Why not rely only on the four solvers and remove assurance layers?

Solver agreement alone does not prove that:

  • strategies are complete
  • selected edges are legal
  • regions are closed
  • recurrent cycles have correct parity
  • evidence identities are intact
  • disagreements can be localized
  • governance conditions are satisfied

The assurance layers address these separate questions.

K5. Why is strategy diversity valuable?

Four distinct strategies show that the common winner partition is compatible with multiple valid move selections.

This reduces dependence on one exact strategy artifact.

It does not by itself prove solver independence or universal correctness.

K6. Why use exact integer and categorical decisions?

Proof decisions avoid floating-point tolerance ambiguity.

The supplied campaigns use integer and categorical proof decisions rather than floating-point proof thresholds.

floating-point proof decisions = false

This improves replay stability and exact comparison.

K7. Can SSG fail?

Yes.

Possible failure sources include:

  • algorithm defects
  • checker defects
  • common schema defects
  • incomplete challenge coverage
  • unsupported graph classes
  • incorrect physical mapping
  • corrupted evidence
  • misunderstood claim scope

The repository is designed to make such failures easier to expose and diagnose.

K8. What would be the strongest next evidence?

High-value next evidence includes:

  • additional independently generated parity games
  • wider priority ranges
  • external solver comparisons
  • independent reimplementations
  • independently designed fault campaigns
  • external review of certificate semantics
  • domain adapters with measured physical evidence

SECTION L — Falsification

L1. Can SSG be challenged?

Yes.

Independent replay, mutation, reimplementation, and falsification are encouraged.

L2. What are useful falsification targets?

Attempt to produce:

  • same canonical graph -> different graph subject
  • same canonical graph -> different winner partition
  • changed winner -> family consensus accepted
  • missing strategy entry -> transition truth accepted
  • extra strategy entry -> transition truth accepted
  • illegal selected edge -> transition truth accepted
  • selected move leaving the region -> transition truth accepted
  • opposing move leaving the region -> closure accepted
  • adverse recurrent cycle -> winner certificate accepted
  • corrupted certificate -> evidence admitted
  • observatory mismatch -> healthy diagnostic state
  • unresolved incident -> release certified
  • fewer than four admitted solvers -> federation certified
  • row-order change -> structural certificate changed
  • successor-order change -> structural certificate changed
  • network required -> offline campaign passes
  • external solver required -> complete campaign passes

Primary target:

invalid structural transition -> valid closed-return certificate

L3. What happens when falsification succeeds?

A reproducible prohibited outcome is valuable evidence.

It should lead to one or more of the following:

  • correct the implementation
  • strengthen the checker
  • expand the fault campaign
  • narrow the documented claim
  • withdraw the affected certificate
  • issue a corrected release

L4. Does successful falsification invalidate the entire research direction?

Not necessarily.

It identifies the exact limit of the current implementation or claim.

A useful research system must be able to expose, localize, and respond to such evidence.

SECTION M — Extension

M1. Can another solver be added?

Yes.

A new solver should provide:

  • the canonical winner partition
  • a positional strategy
  • native work evidence
  • a solution certificate
  • an independent checker
  • fixtures
  • mutation cases
  • metamorphic checks
  • deterministic replay

The component registry and assurance layers would then need a corresponding governed extension.

M2. Can another parity game be used?

Yes.

The new subject should define:

  • vertices
  • owners
  • priorities
  • successors
  • canonical serialization
  • structural identity
  • expected evidence contract

The current frozen certificate values would not apply to a different game.

M3. Can SSG connect to physical simulations?

Yes, as a research extension.

A physical adapter would need to define:

  • how measured or simulated states become graph states
  • what transitions are admissible
  • what represents return
  • what represents redistribution
  • what represents arrest
  • what constitutes escape
  • how uncertainty is represented
  • how the mapping is validated

The adapter would require its own evidence and claim boundary.

M4. Can SSG work with external evidence?

Yes.

External evidence should be admitted through explicit identity, provenance, schema, completeness, and trust boundaries.

The current bundled assurance chain does not independently authenticate evidence generated outside the package.

SECTION N — Short Answers

N1. Is SSG deterministic?

Yes, for the frozen inputs and implemented certificate rules.

N2. Is SSG offline?

Yes, for the supplied campaigns.

N3. Does SSG need administrator rights?

No.

N4. Does SSG require an external solver?

No.

N5. Does SSG require an external dataset?

No.

N6. Does SSG contain physical validation?

No.

N7. Do all four solvers agree?

Yes, on the frozen winner partition.

N8. Do all four solvers use the same strategy?

No.

They preserve four distinct valid strategy identities.

N9. Are adverse recurrent cycles present in the certified strategies?

No.

STRAL reports:

total_bad_recurrent_cycle_count = 0

N10. What is the final system state?

RELEASE_CERTIFIED

⭐ Final One-Line Summary

SSG investigates stability as a closed return relation and demonstrates one deterministic finite-game realization through four native solvers, four assurance layers, exact transition verification, disagreement diagnosis, replayable evidence, and governed certification.

🌌 Final Insight

A balanced state describes where a system is.

A closed return relation describes what the system can survive.

SSG therefore asks:

When an admissible disturbance enters the structure, do all admitted paths remain enclosed by return, redistribution, or arrest before escape becomes recurrent?

Balance Is a Closed Return Relation.