Methodology and technical doctrine

Interface-First Execution Methodology (IFEM)

Explicit interfaces. Confident execution. IFEM organizes complex software work around responsibility boundaries, explicit contracts, and independent verification.

Why IFEM exists

Software work divided among people, teams, or AI-assisted tools does not become dependable through local speed alone. Each contributor needs to know what it owns, what it promises across a boundary, and how that promise can be checked independently. IFEM makes those agreements visible as a connected path from intent to runtime.

The seven-phase model

This is not a project-management template or a software product. Each phase strengthens the next phase’s input: Intent frames the outcome; Architecture exposes responsibility; Interfaces define the observable surface; Contracts freeze the agreement; Execution permits independent implementation; Verification turns agreement into evidence; and Runtime observes whether the boundary holds in operation.

  1. Intent
  2. Architecture
  3. Interfaces
  4. Contracts
  5. Execution
  6. Verification
  7. Runtime

Authority and publications

IFEM is authored by Soheil Mozaffari, software engineer and systems architect. It is presented as a methodology and technical doctrine, not as a certification scheme or adopted standard.

GitHub · Soheil Mozaffari’s personal site

How to read the doctrine

To use the doctrine, begin by stating the outcome that must become dependable, then make responsibilities and boundaries visible. Interfaces, contracts, and independent execution build on those decisions, while verification shows whether the agreement holds in practice. Runtime brings operational feedback back into the next deliberate decision. These pages can be read independently, and their links expose the methodology as a connected sequence rather than a checklist. The result is a shared vocabulary for discussing change: intent explains the outcome, architecture explains accountability, interfaces and contracts explain the boundary, execution produces the implementation, verification produces evidence, and runtime exposes what the environment teaches. This vocabulary keeps technical decisions visible as systems evolve.