SAF principles

Sufficient model

A model should contain the minimum information required for a concrete decision. A new object type or attribute is justified when an important question, responsibility, or change impact cannot be handled without it.

Progressive detail

One concept evolves without losing identity. For example, “customer data” may first be an integration label, then become an information object, and in the enterprise profile split into a business object, data object, and message.

Stable identity

An identifier does not depend on a name, owner, technology, or current state. As the model grows, an object is refined rather than recreated under a new identifier.

Explicit semantics

Every relationship reads as a meaningful statement: “process realizes service,” “component exposes interface.” A generic “related to” relationship is acceptable only as temporary catalog debt.

Separation of concerns

A business capability describes what the organization can do. An interface describes how a component can be accessed technically. A deployment separates a logical component from its running instance.

Ownership as a relationship

An owner is not a free-form string. A significant object is connected to an actor of kind role, team, or organizational unit through an ownership relationship.

Verifiability

Rules should detect unresolved references, unknown endpoints, ownerless objects, and stale information. At higher maturity, fewer critical rules remain informal agreements.

Tool independence

SAF defines model meaning but does not prescribe YAML, a database, a notation, or a product. Text, tables, and graphs are acceptable if identifiers, types, and relationship semantics are preserved.