ADR-004: Relation Filtering Algorithm in Views

Status

Accepted

Context

The predecessor prototype 1_mde-plantuml separated model/ from views/ and introduced the slice_view() algorithm. That algorithm filtered relations based on the set of elements selected by a view.

SOTER needs the same concept in a more explicit and documented form.

Decision

SOTER adopts three relation filtering modes for .view definitions:

• touching-only: Include a relation only when both ends belong to the view.
• all: Include a relation when at least one end belongs to the view.
• none: Skip relations and show only elements.

touching-only is the default.

Rationale

Views must act as lenses over the model. Relation filtering gives each lens a clear rule for how much context it exposes while keeping the source model unchanged.

Consequences

Positive

• Views can control relation scope declaratively.
• The source model remains stable across different audience perspectives.
• Contextual and strict views are both possible.

Negative

• Users must understand that relation visibility is a view-level choice.
• Overly broad all views can become visually noisy.

Neutral or Operational

• The implementation descends from tools/build.py::slice_view() in the retired prototype.

Alternatives Considered

Always Include All Relations

Rejected because it produces noisy views and weakens audience-specific projection.

Always Include Only Internal Relations

Rejected because contextual views sometimes need external connections.

Migration or Adoption

Existing views should declare relation filtering explicitly when their behavior differs from touching-only.

Related Documents

• DocumentationStyleGuide.md
• writing profile and document-type rules.
• AdrTemplate.md - ADR document template.
• AdrIndex.md - architecture decision record index.
• ProjectionOverview.md - projection layer entry point.