The New Object

Software evolution as a computable object

SFT moves from observing past code states to asking which architecture futures are reachable under a selected field model. Computable means bounded by explicit modeling choices, not completely decidable in reality.

software evolution
  = artifact-shaped operation space
  + governance-shaped selection policy
  + observable signature trajectory
  + feedback-updated field memory

The theory is organized into theory, measurement, computation, and governance layers. AAT supplies local algebra, ArchSig supplies observation, and SFT asks how future operation space changes under artifacts and feedback.

computable :=
  representable under an explicit modeling boundary
  + bounded by a selected horizon, universe, and observation axes
  + reducible to reachability, support inference,
    cone generation, safety preservation,
    proposal accounting, feedback update, or calibration

This is a bounded-computation claim. SFT does not say the real project history is fully decidable; it says selected questions can be made finite, auditable, and explicitly relative to the evidence and horizon that were chosen.

Codebase as field memory

A codebase records more than implementation state. It also carries requirements, design decisions, review patterns, incidents, workarounds, migrations, ownership boundaries, tooling practice, and latent default paths.

• Static shape is not enough The same module graph can support different future operations when field memory differs.
• Local patterns matter Old shortcuts and AI-readable local conventions can make unsafe paths look natural or low cost.
• History constrains future work Past incidents, review rules, and migrations change the support and policy visible to new proposals.

Development field

`DevelopmentField` names the broad field around a codebase: requirements, planning artifacts, design practices, developers, AI agents, review systems, CI, runtime observations, incidents, and lifecycle pressure.

SFT does not claim to fully model human intention or organization culture. It takes a modeling boundary and builds a partial `SoftwareFieldEstimate` that records selected evidence, unavailable evidence, and the unknown remainder.

model_B : DevelopmentField -> Partial SoftwareFieldEstimate

SoftwareFieldEstimate
  = modeling boundary
  + extracted SoftwareField
  + evidence status
  + unknown / unmodeled remainder

Architecture futures and signature trajectories

SFT tracks trajectories, not only endpoints. A safe final state does not imply a safe path, and a net signature delta of zero can hide unsafe intermediate excursions.

ArchitectureFuture
  = field path
  + architecture projection path
  + observed signature trajectory
  + obstruction witness candidates
  + forecast boundary

The coupon PRD running example shows how one artifact can make several paths visible: lawful policy insertion, payment adapter shortcut, UI-only drift, and rounding semantics obstruction.

Claim boundary and non-conclusions

Part I introduces the object and its modeling discipline. It does not prove that all relevant development context can be extracted from a repository, that a field estimate is complete, or that a reachable future is an empirical prediction.

• Definition level `DevelopmentField`, `SoftwareFieldEstimate`, `ArchitectureFuture`, and `SignatureTrajectory` are vocabulary for bounded modeling.
• Computational reading Inputs are selected artifacts, code regions, observations, governance records, unavailable evidence, and a horizon.
• Running example The coupon PRD is used as an artifact action whose possible paths are constrained only after the boundary is stated.