Software Field Theory
A computational theory of field-shaped software evolution.
SFT treats software evolution as bounded computation over field models, operation support, policy, forecast cones, consequence envelopes, governance interventions, and feedback updates.
Reading order
The repository keeps the SFT monograph as the source of truth. The website splits it by Part so readers can move through the theory without losing the boundary between exposition, formalizable schema, tooling estimates, and empirical work.
Each Part page follows the same contract: it states the local definitions, gives the formal or computational reading, names examples and the coupon PRD running thread where relevant, and keeps non-conclusions visible beside the positive claims.
- Part I. The New Object Software evolution as a computable object, codebase as field memory, development fields, and signature trajectories.
- Part II. Algebraic and Observational Basis AAT dependency, ArchSig observation, claim levels, and the one-way interface discipline.
- Part III. SFT Core SoftwareField, artifact-mediated change, operation support, policy, ForecastCone, and FieldUpdate.
- Part IV. Principles and Theorems ForecastCone narrowing, support safety, proposal accounting, feedback update, and stable regions.
- Part V. Computing Systems Built from SFT Computational problems, simulator maturity, AI governance, review systems, lifecycle, and benchmarks.
- Part VI. Case Studies Coupon PRD, migration, incident response, AI-generated shortcut, and end-of-life decision.
- Part VII. Non-Conclusions and Research Program Positioning, non-claims, open problems, and the SFT workbench direction.
Computable core
SFT is not a claim that software history is fully determined. Its computable core is the bounded slice obtained after a modeling boundary, horizon, universe, observation axes, support relation, and policy have been made explicit.
SoftwareField
+ arch projection
+ ArtifactMediatedChange
+ OperationSupport
+ OperationPolicy
+ StepRelation
+ ObservationRecord
+ GovernanceIntervention
+ ForecastCone
+ FieldUpdate
The broad development field remains larger than this fragment. The point of the core is to make selected questions finite, bounded, and auditable rather than to erase unmodeled human, organizational, or operational context.
Claim boundary
SFT uses claim levels to separate conceptual interpretation, trace-grounded diagnosis, set-valued theorem schema, probabilistic transition models, calibrated empirical forecasts, and deployed governance systems.
A `ForecastCone` is not a point prediction. A `ConsequenceEnvelope` is a boundary-aware report. ArchSig output is a measurement or estimate, not a Lean proof.
Canonical sources
SFT depends on AAT, but AAT does not depend on SFT. The interface document keeps this direction explicit and prevents AAT theorem status from being reinterpreted as empirical software forecast status.
- SFT monograph `docs/sft/software_field_theory.md` is the canonical long-form theory text.
- AAT / SFT interface `docs/sft/aat_interface.md` states the one-way dependency and forbidden readings.
- Repository entry `docs/sft/README.md` gives the short entry point and vocabulary list.