In this work we present two contributions: physical hypothesis (SFT) and a verification protocol designed to test it, which by its generic nature can be reused to evaluate any similar field theory. The protocol is built around a structured sequence of artifacts—SCAN, REGION, and REPORT—together with pre-registered gates, schema-validated outputs, and deterministic verification tools. Its purpose is to provide a clear, transparent, and falsifiable framework that allows independent reviewers to assess specific claims without ambiguity. Beyond its role as a verification mechanism, the protocol also functions as a practical research compass. Each module produces explicit PASS or FAIL outcomes tied to well-defined metrics and thresholds. A FAIL is not merely a negative result: it identifies the precise gate, metric, and artifact where the breakdown occurs, offering immediate diagnostic information. This structure enables rapid iteration, guiding model refinement and helping researchers navigate complex hypothesis spaces efficiently. We believe this work aligns well with methodological rigor, openness, and reproducibility. We hope it will be of value to researchers working on computational physics, speculative frameworks, and verification-driven scientific practice. SFT — Structural Field Theory (Docs + Runners) This repository is a verification-first release of SFT: a theory/framework plus a set of runners designed for external audit. Start here: read Doc 0 — Abstract & Orientation for the ontological stance, scope, current limitations, and falsifiable predictions. The key idea is simple: The “vacuum” is treated as a structural medium/field. “Particles” are stable field configurations (discrete in manifestation, continuous in availability). The project is organized so third parties can verify pipelines via PASS/FAIL gates, hash manifests, and schema-validated artifacts. Important: many included datasets are synthetic (C) because this release is built to be verified on CPU-only.Physical end-to-end confirmation requires REAL (P) solver outputs. CI only validates the verification pipeline (CPU-only), not physical validation. REAL-ready: verifiers + artifact contract are in place; can consume third-party real-solver outputs. REAL-verified: a real-solver run has been published with artifacts + hashes and passes the declared gates. Repository structure Doc_01/ ... Doc_14/ The full documentation set (each doc in its own folder). *_CLEANED.zip and runner bundles When a document has an executable verification component, the corresponding zipped runner bundle is included. https://github.com/Xaquer69/sft-theory-and-runners