AAT/SFT Research Notes

SFT Part VII

Non-Conclusions and Research Program

Part VII states what SFT is not, what it does not claim, which formal and empirical problems remain open, and how the workbench direction ties the theory back to tooling.

Positioning

SFT is not a static architecture metric, software process model, DevOps maturity model, technical debt taxonomy, AI coding benchmark, or replacement for formal verification.

Its difference is that software evolution itself becomes the computational object: artifacts and feedback reshape support, governance changes selection policy, observation determines signature trajectories, and consequence envelopes describe reachable architecture futures.

What SFT does not claim

  • No mechanical future determinism SFT does not claim that future software behavior is mechanically determined.
  • No automatic empirical forecast A `ForecastCone` does not become an empirical prediction without calibration.
  • No trajectory safety from AAT alone AAT theorem status does not imply future field trajectory safety.
  • No safety from unmeasured axes Observed zero and unmeasured are different statuses.
  • No ground truth extractor claim ArchSig extraction is not a complete `ComponentUniverse` or ground truth architecture object.
  • No causal uniqueness from observed deltas An observed signature delta does not uniquely identify the artifact action that caused it.
  • No policy-to-lawfulness implication AI policy compliance or review acceptance does not imply architecture lawfulness.
  • No human or market prediction SFT does not predict human intention, organizational success, or market success.

Open problems

The research program includes Lean formalization of `ForecastCone` and support simulation, the relation between `ConsequenceEnvelope` and cones, trace-grounded field reconstruction, simulator calibration, review mediation and AI shortcut benchmarks, theorem-boundary integration, field memory studies, lifecycle models, and deployed closed-loop workbench design.

Research direction
formal core
  + observable field estimates
  + calibrated simulator benchmarks
  + review / CI governance integration
  + lifecycle and AI proposal governance
  -> deployed SFT workbench
  • Formal open problems Lean formalization of `ForecastCone`, support simulation, and the relation from envelopes to one or more cones.
  • Empirical open problems Trace-grounded reconstruction, simulator calibration, review mediation, AI shortcut detection, and field memory studies.
  • Tooling open problems Theorem-boundary integration, lifecycle decision models, and a deployed closed-loop workbench.

Workbench direction

The SFT workbench should take PRDs, design memos, issue plans, codebase state, architecture signatures, review and CI history, incident history, and AI policy. It should return a consequence envelope, affected axes, witness families, missing boundaries, risky default paths, issue decomposition, review or CI interventions, AI proposal constraints, and calibration plans.

Workbench contract
input:
  PRD, design memo, issue plan, codebase,
  architecture signature, review / CI history,
  incident history, AI agent policy

output:
  ConsequenceEnvelope, affected axes,
  witness families, missing boundaries,
  risky default paths, issue decomposition,
  governance interventions, AI constraints,
  feedback / calibration plan

SFT does not replace developers. It makes software evolution visible as something that can be observed, bounded, computed, governed, and revised.

Research boundary

The research program is deliberately split across formal, tooling, and empirical tracks. Lean work can prove bounded schemas; ArchSig and the workbench can produce evidence and reports; calibration studies can test forecast quality. None of these statuses should be collapsed into the others.

This page therefore treats SFT as a large computational theory with visible non-conclusions. The scope is broad, but every claim must still state whether it is defined only, theorem-shaped, tool-supported, empirically calibrated, or operationally deployed.